Page 1 of 2 12 LastLast
Results 1 to 10 of 19

Thread: Announce: My remake of robotron with DelphiX

  1. #1

    Announce: My remake of robotron with DelphiX

    So you can see the progress, I`ve made a little site:

    http://norrish.force9.co.uk/robotron

    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.)

  2. #2
    Legendary Member cairnswm's Avatar
    Join Date
    Nov 2002
    Location
    Randburg, South Africa
    Posts
    1,537

    Announce: My remake of robotron with DelphiX

    It would be nice to have some screen shots up on the site for us to see.
    William Cairns
    My Games: http://www.cairnsgames.co.za (Currently very inactive)
    MyOnline Games: http://TheGameDeveloper.co.za (Currently very inactive)

  3. #3

    Announce: My remake of robotron with DelphiX

    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.
    Isometric game development blog http://isoenginedev.blogspot.com/

  4. #4

    Frame rate / game timer

    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!!

  5. #5

    No screenshot

    Quote Originally Posted by cairnswm
    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

  6. #6

    Game timer

    Frustratingly, I still cannot get a timer independant update to work at all. I have tried to implement Alimonster's method here, 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:

  7. #7

    Announce: My remake of robotron with DelphiX

    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

    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.
    Code:
    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 :

    Code:
    procedure TForm1.OnIdleHandler(Sender: TObject; var Done: Boolean);
    begin
       processGameEvents ;
    
       if stopGame then form1.Close;
       done:=false;
    end;
    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)
    Code:
    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
    Code:
    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.

  8. #8

    timing

    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


  9. #9

    Announce: My remake of robotron with DelphiX

    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.

  10. #10

    pop baloon source

    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?

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •