View Full Version : Announce: My remake of robotron with DelphiX

17-01-2005, 11:27 PM
So you can see the progress, I`ve made a little site:


Any of the fx or technique seen here that you want help with, please ask at the site address.
I might do a tutorial, but it won't be as nice as Travellers :)

There's a signup option on the site so you can be notified of significant updates.

{oh.. I`ve solved a few problems on the way, which some other people I have seen asking after: modify palette of source graphic, pixel based sprite collision problem etc.)

18-01-2005, 03:40 AM
It would be nice to have some screen shots up on the site for us to see.

18-01-2005, 03:34 PM
I played the demo and I gotta say I love it already. Robotron is one of my fave retro games so I looked forward to playing your remake and so far it looks good. Few issues though, the framerate is very inconsistent due to the amount of objects on screen at a time but since the game speed is actually tied into the framerate it causes problems, this needs addressing (Sorry to patronise if you already had this planned). I think the biggest frame killer is the use of Alpha Blending. DirectDraw and DelphiX especially are notoriously slow at Alpha Blending so I think if you drop the alpha blending it will help a great deal. I was getting just 39fps on a 2.8Ghz with GeforceFX 5800 and 1Gb of RAM. This won't be so much of an issue if you have the game speed independant of the framerate but it still needs sorting. I know it's early days but problems like this need sorting as early as possible so you know it won't be unplayable when you reach the higher levels with more enemies on screen. Good luck and despite what I just said, I really do love it so far.

18-01-2005, 10:47 PM
Tell me about it. I have tried using a non-timer update I found on here (or gamedev), but couldn't get it working. If you've got a framework I could use, then I`d be really grateful!!

18-01-2005, 10:51 PM
It would be nice to have some screen shots up on the site for us to see.

Will put some on when the proper graphics arrive - not a lot to see yet

19-01-2005, 08:24 PM
Frustratingly, I still cannot get a timer independant update to work at all. I have tried to implement Alimonster's method here (http://www.pgd.netstarweb.com/viewtopic.php?t=1163), but to no effect... I don't know if I`m doing this correctly.
I place my DXSpriteEngine1.Move() into the app.onidle event and call MyGameTimer.Update in the DXTimer1Timer... nothing happens, and I have to admit, I don't really see why.

I don't know the whole picture - should I be doing renders in the timer or the "update" or what? I`ve tried all kinds of combinations, but no luck.. :cry:

19-01-2005, 09:27 PM
Let me begin to say that its a really good start. After the first killing frenzy, I was eagerly awaiting the next bunch of robots, only to realize moments later that there was probably nothing more to come. :?

It ran smooth as silk on my system, but I imagine with 3ghz, 1gig ram and a 6800 gt gfx card it better had to :D

Anyway, on to your question. The whole independant timer thing can be a bit tricky at first, but once you've figured it out, its really easy.

What you gotta do is this:
Create a procedure, called something like processGameEvents. In it you place all the code that draws to the screen or updates your sprites movements. (l'll get back to the movement later)

Then there's a event called OnIdleHandler.

procedure TForm1.OnIdleHandler(Sender: TObject; var Done: Boolean);
In this procedure you call processGameEvents unless a variable, called something like stopGame becomes true (like a backdoor) so you can terminate the application. Like this :

procedure TForm1.OnIdleHandler(Sender: TObject; var Done: Boolean);
processGameEvents ;

if stopGame then form1.Close;

Lastly in the oncreate event set Application.OnIdle := OnIdleHandler;

Thats all there is to it.

Now about movement. If you do something like sprite.x := sprite.x + 2, which normally is a good value when using the dxtimer component, your sprites will now suddenly move insanely fast.

In order to let an object move at the correct speed each frame, you have to calculate the time between frames. (in the processGameEvents procedure)

NewTime := TimeGetTime;
UpdateSpeed := (NewTime - OldTime) * OneMSec; { get the speed to update objects }
OldTime := NewTime; { store this value for the next update }
Together with the UpdateSpeed you can now update the sprites, something like
sprite.x := sprite.x + (0.2 * UpdateSpeed)

I hope this helps you a bit. But in case it doesn't, have a look at the source from Pop the Balloon, on my website. You can find all this in there, be it with slightly different variable names.

19-01-2005, 11:25 PM
Ok.. I`ll look at the pop baloon source tomorrow. I think I got the Alimonster method working (well, stuff is moving around) but there's no improvement.
I have several questions:

Should wait for vblank still be on?
Unless I multiplied my movements by HUNDREDS ie. x:=x+2 becomes x:=x+(200*elapsed), nothing moved.
Movement is as jerky as before (if not more!)
I had to kill the dxtimer, or application.idle didn't occur...
I set tickrate to all sorts of values and no discernable difference


20-01-2005, 07:56 AM
Should wait for vblank still be on?

I doubt it'll be necessary. Vblank is usually turned on as a last attempt to get fps up. With todays hardware it should not be a real problem to get your game running at a good fps. Unless you're going to make extensive use of Alpha blending.

In any case, I would leave the choice to the end user by presenting it in some kind of option panel.

Unless I multiplied my movements by HUNDREDS ie. x:=x+2 becomes x:=x+(200*elapsed)

It is possible that your elapsed time value is something like 0.05.
2*0.05 = is way too small to make your sprite move.

Movement is as jerky as before (if not more!)
It could be caused by a number of things, I can't tell without seeing the code.

I had to kill the dxtimer, or application.idle didn't occur...
Because application.OnIdle takes care of the gameloop, there's no reason to have the dxtimer component on your form as well.

I set tickrate to all sorts of values and no discernable difference
I'm not really sure how dxtimer's tickrate works. I've seen some code here on the forum that uses tickrate, but never tried it myself. In any case with the new timer there's no need to use tickrate.

20-01-2005, 12:50 PM
Well, I looked at the popbaloon source and the timer stuff makes perfect sense :)

The only thing I still am unsure of: to adjust the target FPS, would you adjust the variable OneMSec, as this would appear to affect all movement?

If, in my existing code I had values already, such as x:=x+2 which now should be x:=x+(2*UpdateSpeed) or so, If I wanted to retain my original FPS target of 60FPS which I was getting with the VBLANK, how is the OneMSec / UpdateSpeed adjustable for this?

20-01-2005, 01:37 PM
The users pc updates as often as possible. When he's using a slow pc it may be possible that his pc can't keep up and the gap between two frames will be made larger, because it takes more time to process a frame, meaning the sprite is moving more irregular. (This is the same effect when playing for example in an online FPS, where you have a high ping rate and you see yourself suddenly jump forwards).
However, users with a more powerful pc who can keep up, may not experience that slowdown because the gap between to frames remains small.

I would recommend leaving the UpdateSpeed calculation alone and only change the speed of your sprites to a value you're comfortable with.

21-01-2005, 10:35 PM
Many thanks. I think the independant update is working correctly now.
Please take a look and I`m working on some screenshots for the site now :)

22-01-2005, 12:11 PM
Looks great! Especially the flashy transition to the next level. Very nice!
Keep us posted.

Btw, thanks for the credits!

23-01-2005, 07:56 PM
Upated - info on site. Screenshots too :)


26-02-2005, 11:07 PM
Site, demo and screenshots updated.
I`m now using Jaro's accelerated UndelphiX, although not using hardly any of the hardware accelerated routines yet.

02-05-2007, 12:25 AM
Work has since resumed on this project and there have been some major updates.

Please check the site for all details and download

(see first post in this thread for URL)

02-05-2007, 08:40 AM
Wow, welcome back and the screen shots look fun. Any chance of an in game movie?

02-05-2007, 04:29 PM
Wow, welcome back and the screen shots look fun. Any chance of an in game movie?

Yea, no problem. I'll do one tonight and stick it on google video / youtube. I`ve noticed that people would rather see a video rather than the game these days? Still, I'll get the video editor out and make a nice little trailer for it - at least it's another advertising medium as well :)

05-05-2007, 09:14 AM
I tried it, but no luck. Seems to be a known problem with recording DelphiX games with Fraps etc. Just toooo low a framerate.