Superfrog kind-of-fan-clone public tech demo

Whatever you're working on - be it Art, Music, a Fan-Game or a program for use with existing Team17 games - we want to hear about it.

Moderator: Dream17 Staff

User avatar
SupSuper
leek hackspinn0r
Posts: 377
Joined: Mon Feb 28, 2005 5:04 am
Location: Portugal
Contact:

Post by SupSuper » Wed Jan 24, 2007 9:35 pm

Moxy wrote:
SupSuper wrote:Another note, you might wanna add acceleration to SuperFrog's X movement, like the original had. Plus every proper platformer has acceleration. ;)
There is proper acceleration. The max velocity or acceleration is probably too slow or subtle for it to be obvious, if you open up Media/Player.XML and change values there, you can set velocities to whatever you like. (but not in the custom versions I've been sending you - cos they're hardcoded).
You're right, he does slide, but he doesn't do it smoothly, he seems to stop a lot more abruptly than in SuperFrog.

Also, for accuracy, the original SuperFrog only flashes for 3 seconds. Oh and he goes slower up slopes and faster down them. ;)
Team17 Forum Refugee | OpenXcom Developer

Moxy
Newbie
Posts: 36
Joined: Wed Nov 29, 2006 6:15 am
Contact:

Post by Moxy » Thu Jan 25, 2007 1:40 am

Thanks Pooka :)
SupSuper wrote:he does slide, but he doesn't do it smoothly, he seems to stop a lot more abruptly than in SuperFrog.

Also, for accuracy, the original SuperFrog only flashes for 3 seconds. Oh and he goes slower up slopes and faster down them. ;)

That abrupt stop is by design - I found things a bit too slippery in the real game, and found it a bit annoying. As I build the later levels, I might make it take a bit longer to stop.

The way it's done is via deceleration - just like the acceleration, but in this case, the deceleration is real fast.

Yup, I'll have flash pretty-much-the-same for next release, and the slope speed thing :)

Thanks everybody for pointing out these things :)

User avatar
Bloopy
Regular
Posts: 233
Joined: Mon Jun 20, 2005 1:07 pm
Location: New Zealand
Contact:

Post by Bloopy » Thu Jan 25, 2007 9:06 am

Moxy wrote:I see you are from NZ, also. Which city are you in?
Wellington! And you?
x_+

Moxy
Newbie
Posts: 36
Joined: Wed Nov 29, 2006 6:15 am
Contact:

Post by Moxy » Thu Jan 25, 2007 9:10 am

Bloopy wrote:
Moxy wrote:I see you are from NZ, also. Which city are you in?
Wellington! And you?
Awesome, I'm in Wellington also.

Moxy
Newbie
Posts: 36
Joined: Wed Nov 29, 2006 6:15 am
Contact:

Post by Moxy » Thu Jan 25, 2007 2:10 pm

Ok, here is a new release. I'm trying to get any weirdness tied up before I fully build the rest of the levels, and add scoring, etc.

http://www.lithiumdream.com/superfrog/S ... 25-D17.zip

I think I _may_ have fixed the "you get death" looping (I can't replicate on either of my machines) - however, I added a bit of logging to work out where the problem occurs - if it does occur, so if it comes up for one of you guys, can you please email or pm me the "applog.txt" file - make sure you make a copy of applog.txt immediately after you close the game - it gets overwritten every time platformer.exe is launched.

Other than that:
------
The jitter should be fixed - if the problem was caused by what I think it was caused by.

The left-right movement is more like superfrog; now he'll keep sliding in his original direction just a little bit, before changing direction - rather than the hard switch like before.

Things are a little more slippery in general.

Flash time has been cut down to 3 seconds.

User avatar
SupSuper
leek hackspinn0r
Posts: 377
Joined: Mon Feb 28, 2005 5:04 am
Location: Portugal
Contact:

Post by SupSuper » Thu Jan 25, 2007 2:37 pm

Yeah the sliding is better now, though now I can move left-right during the "ow that hurts jump", which can lead to neat combinations like killing myself twice at once. :P
Team17 Forum Refugee | OpenXcom Developer

Moxy
Newbie
Posts: 36
Joined: Wed Nov 29, 2006 6:15 am
Contact:

Post by Moxy » Thu Jan 25, 2007 3:04 pm

SupSuper wrote:Yeah the sliding is better now, though now I can move left-right during the "ow that hurts jump", which can lead to neat combinations like killing myself twice at once. :P
haha lol a bit of an oversight there.

I just updated the download a couple seconds ago. The unfortunate kill-yourself-twice-at-once trick should be no more :)

User avatar
Pooka
Staff Writer
Posts: 361
Joined: Mon Feb 28, 2005 8:57 pm
Location: London
Contact:

Post by Pooka » Thu Jan 25, 2007 8:31 pm

A few things I've noticed (not praise or criticisms, take these as you will):

* Enemy collision's super-sensitive. That first hedgehog got me before I knew it!
* It runs a bit smoother in fullscreen, IMHO.
* I like the new speed and the slipperiness recalls the original SF quite nicely.
* You can't defeat the wasps by jumping on them, you just get hit.
* I like the title screen!

Other than that, nothing much different I can see. No errors here.
Superfrog: the best things in life are green.

Moxy
Newbie
Posts: 36
Joined: Wed Nov 29, 2006 6:15 am
Contact:

Post by Moxy » Fri Jan 26, 2007 12:01 am

Pooka wrote: * Enemy collision's super-sensitive. That first hedgehog got me before I knew it!
* It runs a bit smoother in fullscreen, IMHO.
Cool, enemy death hasn't been added yet.

I'm not sure what to do about the enemy collision though. I guess I could make the enemy bounding boxes a little bit smaler. Do you mean the bounding box is too big?

The windowed non-smoothness is a hardware thing, I think. I don't really intend for the final version to be played in windowed mode. Was the jittering gone for you when you were running in fullscreen?

K^2
Regular
Posts: 216
Joined: Thu May 26, 2005 4:02 am

Post by K^2 » Sat Jan 27, 2007 4:32 am

Why not do a per-pixel collision test once you have bounding-box collision? It shouldn't take too long if you only test the enemies that are already crossing your bounding box.
None of my projects (Minus One converter, W3D/W4 Map Viewer, and WMapEditor) are endorsed, supported or otherwise affiliated with Dream17. I just find Dream17 forums to be a nice place to share and discuss my work with others.

Moxy
Newbie
Posts: 36
Joined: Wed Nov 29, 2006 6:15 am
Contact:

Post by Moxy » Sat Jan 27, 2007 8:16 am

K^2 wrote:Why not do a per-pixel collision test once you have bounding-box collision? It shouldn't take too long if you only test the enemies that are already crossing your bounding box.
Yeah, I could do that. There are a few ways I could do it.

Which way would you recommend? (keep in mind that I'm using DX8/OGL)

K^2
Regular
Posts: 216
Joined: Thu May 26, 2005 4:02 am

Post by K^2 » Sat Jan 27, 2007 8:42 pm

The "dirty" method of doing this is keeping a copy of texture you use for a sprite in RAM as a bitmap, and just testing it with custom code. For example, something like this should work.

Code: Select all

//sprite1 and sprite2 are RGBA 32bit raw bitmap data.
//x1,y1,x2,y2 are the coordinates of the sprites.
//w1,h1,w2,h2 are width and height of two sprites.
int collisionTest(char *sprite1, char *sprite2, int x1, int y1, int x2, int y2, int w1, int h1, int w2, int h2)
{
int xp1, yp1, xp2, yp2;
for(yp1=0;yp1<h;yp1++)for(xp1=0;xp1<w;xp1++)
{
if(!sprite1[4*(w1*yp1+xp1)+3])continue;//Transparent, no collision.
xp2=x1+xp1-x2;
yp2=y1+yp1-y2;
if(xp2<0 || xp2>=w2 || yp2<0 || yp2>=h2)continue; //Out of bounds, no collision.
if(!sprite2[4*(w2*yp2+xp2)+3])continue;//Transparent, no collision.
return 1; //Collision. It only takes one pixel.
}
return 0; //No collision.
}
Considering the fact that you don't really have a reason to worry about optimal performance, and that you probably keep a copy of sprites in RAM anyways, this should work rather neatly.

There is an alternative. If you are rendering in 3D, which you probably are if you are using DX8 or OGL, you can use the combination of depth and stencil buffers to do the dirty work for you. For every frame, you want to clear depth and stencil buffers. Set some reasonable depth. Add an alpha test. Test must fail if you try to draw a pixel with 0 alpha. Otherwise, you will still get a collision on transparent pixels. Set depth test to greater then. Set reasonable depth. Set stencil buffer to increment on failed depth test, and no change on pass. Stencil test is disabled. Now, render all collidable sprites first. Once all sprites are done, check the stencil buffer. Any value>0 indicates collision at that pixel. Now, lower depth, and render background. It will not render over sprites, since depth test will fail there. Finally, disable depth test and render any partially transparent FX. Note: Any collidable sprite with alpha other than 1.0 or 0.0 will cause artifacts, so any translucent sprites must be rendered on FX layer.

I do not recall DX8 functions for stencil operations, but I'm sure you can find them. The OGL functions include:

glStencilOp(GL_KEEP,GL_INCR,GL_KEEP); //Makes sure that stencil buffer is incremented on collision.
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT); //Clears color, depth, and stencil buffers.
glClearStencil(0); //Sets clear stencil value to 0.
glEnable(GL_DEPTH_TEST);//Turns on depth test.
glDisable(GL_DEPTH_TEST);//Turns it off
glDepthFunc(GL_GREATER);//Depth test passed only if Z value is greater.
glEnable(GL_ALPHA_TEST);//Enable it before collision detection.
glAlphaFunc(GL_GREATER,0.0);//Makes sure transparent pixels are not rendered.
glDisable(GL_ALPHA_TEST);//Disable alpha test before alpha blending.
glEnable(GL_BLEND);//Enable alpha blending.
glBlendFunc(GL_SRC_ALPHA,GL_ONE_MINUS_SRC_ALPHA);//Standard blending function for transparency.

There is still a matter of getting to the stencil buffer. There might be a way of accessing it almost directly. I know that depth buffer can be accessed with the glCopyTexImage2D function by substituting the format with GL_DEPTH_COMPONENT. You can try it with GL_STENCIL_COMPONENT and see if that will copy the stencil to texture. Alternatively, switch to an auxiliary buffer (glDrawBuffer(GL_AUX0)) render solid color to the whole screen with all but stencil test disabled and with a stencil test enabled. (glEnable(GL_STENCIL_TEST), glStencilFunc(GL_GREATER,0,1);) The resulting screen should be still cleared in all points other than collision. All you have to do is read pixels from auxiliary buffer to RAM, and do whatever tests you want with the result.
None of my projects (Minus One converter, W3D/W4 Map Viewer, and WMapEditor) are endorsed, supported or otherwise affiliated with Dream17. I just find Dream17 forums to be a nice place to share and discuss my work with others.

Moxy
Newbie
Posts: 36
Joined: Wed Nov 29, 2006 6:15 am
Contact:

Post by Moxy » Sun Jan 28, 2007 7:38 am

K^2 wrote:...
Cool, I'd probably go with the latter, since, with the latter, I wouldn't have the problem of having two paths to debug, and maintain.

However, I hear that reading from gfx memory is extremely expensive, I'll have to look into it and see what the performance implications are - mainly for older, early DX8 graphics cards such as the GF3, etc.

--

Also, has anybody noticed any jitter when playing? I'm guessing that from the silence, everybody is getting smooth gameplay?

K^2
Regular
Posts: 216
Joined: Thu May 26, 2005 4:02 am

Post by K^2 » Sun Jan 28, 2007 9:44 am

Moxy wrote:However, I hear that reading from gfx memory is extremely expensive.
Yes, memory transfers between system RAM and gfx RAM tend to be rather slow. But if you only need one transfer per frame, it's not really a big problem. It would be nicer to capture the event some other way, but I can't think of anything right now.
None of my projects (Minus One converter, W3D/W4 Map Viewer, and WMapEditor) are endorsed, supported or otherwise affiliated with Dream17. I just find Dream17 forums to be a nice place to share and discuss my work with others.

Moxy
Newbie
Posts: 36
Joined: Wed Nov 29, 2006 6:15 am
Contact:

Post by Moxy » Mon Feb 12, 2007 9:41 am

Hi all, here is another update.

Superfrog remake; tech demo - February 12, 2007

I've added scoring, status bar, countdown timer, lives left, energy meter, coin counter, stuff like that. These are essentially working tests, I'll set up a proper font, perhaps re-do the status bar background, etc, for now it's just testing the systems rather than having a finalized look.

There is now a destructospud. Depending on the position of the monster, all monsters can be killed by the spud if you manage to hit them with it, and not have it pass over their heads. All monsters can be killed via jumping on their heads. I'll change this behavior later as things progress.

I optimised some other things, so, I'm guessing there should be no jitter whatsoever for anybody now.

A couple of things which I haven't added yet is tighter collision poly's for the monsters, there is no final death, nothing happens when the timer counts down to zero, and I'm yet to fix up the bee-movement code. No sound effects either.

There's lots more under the hood, that's all I can think of for now. As always, please let me know if there is any weirdness.

User avatar
Pooka
Staff Writer
Posts: 361
Joined: Mon Feb 28, 2005 8:57 pm
Location: London
Contact:

Post by Pooka » Tue Feb 13, 2007 12:14 am

It seems a little more jittery and harder to control, at points. Also, at some times, the screen pauses for a bit, and then SF jumps to the location where he should be in response to what button you were pressing at the time. (May just be: fast game, my computer, though.)

Maybe this is just the game being slick and me not being very good. ;)

*ahem* Anyway... the sparks left by Spud if you throw him into a wall fail to disappear for A Very Long Time if you do so during the introductory 'dark screen'.

I am, however, enjoying the ability to kill all baddies using Spud. I've often wanted to be able to do that.
Superfrog: the best things in life are green.

Moxy
Newbie
Posts: 36
Joined: Wed Nov 29, 2006 6:15 am
Contact:

Post by Moxy » Tue Feb 13, 2007 2:54 am

Pooka wrote:It seems a little more jittery and harder to control, at points. Also, at some times, the screen pauses for a bit, and then SF jumps to the location where he should be in response to what button you were pressing at the time. (May just be: fast game, my computer, though.)

Maybe this is just the game being slick and me not being very good. ;)

*ahem* Anyway... the sparks left by Spud if you throw him into a wall fail to disappear for A Very Long Time if you do so during the introductory 'dark screen'.

I am, however, enjoying the ability to kill all baddies using Spud. I've often wanted to be able to do that.
How much ram do you have? OS? Video card? Is there anything weird in your applog.txt? Have a bunch of errors been dumped in there?

Did you hear any hard disk thrashing while you were playing?

If there are pauses, it could be due to disk access (there shouldn't be any after the game has started, btw - unless you have another background app interfering with the game)
Pooka wrote: *ahem* Anyway... the sparks left by Spud if you throw him into a wall fail to disappear for A Very Long Time if you do so during the introductory 'dark screen'.
Cool, I'll look into the spud code. It's still very new :)

Moxy
Newbie
Posts: 36
Joined: Wed Nov 29, 2006 6:15 am
Contact:

Post by Moxy » Sun Feb 18, 2007 12:26 pm

Ok. More has changed.

Here is the updated file: Lithium Dream Superfrog

http://www.lithiumdream.com/superfrog/S ... 070218.zip

Sound and music has been added - the sound is not final, there is still volume adjustment, and replacement sounds needed. Unfortunately many of the wav files from http://dream17.abime.net/forum/viewtopic.php?t=374 had volumes too high - causing sound clipping, and many sounds such as the pickup coins sound effect, didn't sound right - for the coins I ended up sound effect from another game. The sounds are all there - it's just now a matter of replacing several wav files with files which sound right.

There are lots more monsters added - things are looking a lot more like forest 1-1.

Lots more under-the-hood stuff done as well.

User avatar
SupSuper
leek hackspinn0r
Posts: 377
Joined: Mon Feb 28, 2005 5:04 am
Location: Portugal
Contact:

Post by SupSuper » Wed Feb 21, 2007 2:46 am

Very nice, very nice. Dunno what else to criticize, I like it as it is. :)
Team17 Forum Refugee | OpenXcom Developer

Post Reply