R-Type Deluxe Development Restarted.

All about ST/STE games

Moderators: simonsunnyboy, Mug UK, Doctor Bob Gordon, ICS, Moderator Team

User avatar
bod/STAX
Atari Super Hero
Atari Super Hero
Posts: 508
Joined: Wed Nov 24, 2004 8:13 pm
Location: Halesowen, West Midlands, England

R-Type Deluxe Development Restarted.

Postby bod/STAX » Wed Jan 22, 2014 3:29 pm

This afternoon I decided to boot-up the old STE and begin some more development on this game after a few weeks break.

I've been thinking a lot about the speed issue with this game over X-Mas and a first and obvious speed up was to take out
all sprite masking in the game just like in the original version of R-Type.

Boy does this improve things a lot. The game pretty much runs at a constant 25fps and only slows down a bit when the screen
gets really busy (I could then solve this with sprite multiplexing).

What I should point out about the sprites is that the average sprite is 32x32 in four bitplanes and even sprites that are smaller
the explosions are still 32x32. I took out some masking in the demo version such as the rotated guns and gun turrents to try and
maintain speed. I also took depth into account when blitting and software sprites (bullets) are either 2 plane or 4 plane
(because of movem.l). Also when blitting whatever the sprite depth you still have to mask out 4 planes.

So my question is: Would you want to see all sprites non-masked in the STE enhanced version if it maintains speed of gameplay?

Let me know your thoughts on this.

Bod.
So let it be written, So let it be done. I'm sent here by the chosen one.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: R-Type Deluxe Development Restarted.

Postby dml » Wed Jan 22, 2014 11:16 pm

Cool :)

TBH I have a different opinion on slowdown in these games, than some people might have.

Slowdown itself isn't that bad - what's bad is slowdown when there isn't a good reason for it - or when it actually gets in the way of gameplay.

I remember playing Xenon all those years ago, and noticing slowdown in places where lots of stuff was blowing up. It didn't detract from the game and felt like stuff was happening. Some arcade machines did this and again in many cases it didn't harm the game. So long as the player causes it, it's a kind of feedback.

If it's caused by a big thing appearing onscreen, then again its probably affordable, if it's obvious.

If it happens at random, changes constantly and/or unrelated to action caused by the player, then it is bad - and annoying.

So before you go massively changing everything have a think about what the changes will mean and what you might be giving up.


For a game like RType it probably isn't good to have the framerate changing - so you probably will have to compromise somewhere - but there are sometimes other ways to claw back the time. Keep an open mind. :) e.g. I still wonder if you use the store/draw/restore method, or do you track dirty background tiles and redraw them without storing if they are still inside the physical window?


When you're converting a known game, you're sort of trapped between making it look/feel right and making it perform properly. With original work, you have to be more creative - but there is the advantage that you can always change things to get an agreeable framerate because there isn't a base to compare it with.

User avatar
bullis1
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2301
Joined: Tue Dec 12, 2006 2:32 pm
Location: Canada
Contact:

Re: R-Type Deluxe Development Restarted.

Postby bullis1 » Wed Jan 22, 2014 11:20 pm

Thanks for the update!

As for your question, that's a bit hard to say without a visual comparison of some sort. Also as dml said, slowdown is sometimes acceptable. Lots of arcade shooters have slowdown when things get busy and sometimes it actually helps the gameplay. A balance should be found I guess. What's the performance like when only certain things are masked?
Member of the Atari Legend team

User avatar
bod/STAX
Atari Super Hero
Atari Super Hero
Posts: 508
Joined: Wed Nov 24, 2004 8:13 pm
Location: Halesowen, West Midlands, England

Re: R-Type Deluxe Development Restarted.

Postby bod/STAX » Wed Jan 22, 2014 11:56 pm

I've now got a working version of the game without any masked sprites and there is definatly a much improved
framerate.

The game is pretty much running at 25fps but when the screen is really busy such as midway through the level
during the rotated guns the drop in framerate is more noticeable particularly with the bounce laser. Although
this is constructed from 8x8 2 plane non masked software sprites the longer the lasers the more work it has to do.

I have to recode the blitter restore/store sprites code as now I only need to store the planes that are changed
instead of a four plane block for each sprite. This will also add to the speed-up of the game.

From a visual point of view there is a noticeable change in things as now the sprites are only logically OR'ed
to the screen. I personally don't this it's all that bad though.

I have to agree that noticeable drop in framerate for this game is not good I would love to get this working at
a constant 25fps with only a minor drop in framerate when the screen gets busy.

If I get the blitter store/restore routines working properly over the weekend I might release a version called
R-Type Deluxe "Unmasked" so I can get peoples opinions on this in relation to the demoversion released
last month.
So let it be written, So let it be done. I'm sent here by the chosen one.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: R-Type Deluxe Development Restarted.

Postby dml » Thu Jan 23, 2014 10:47 am

BTW I had some other thoughts about this.

You could actually code-generate your background tiles, even to use the blitter.

Each tile can be inspected to see which planes it uses and if any planes are fully set/cleared. You can then generate a bit of asm which builds that tile (partly from fills/clears, partly from copies). The tile code is executed via a translation table, with a pointer to the tile data (either the original data or some prepared version of it).

To 'undraw' a sprite all you need to do is track which tiles got dirtied (e.g. a big bitfield), and execute the code for the correct tile types at each dirty tile position. This can be done in quite a fast, compact loop. The advantage is you aren't copying bytes you don't need to. There is no storing before drawing a sprite, and no restoring to planes which can be erased or filled.

Since it's an ST with no CPU cache, you might even break the tile down into 3 or 4 sections with a different bit of asm for each section, where it helps.

There are probably 10 other ways, maybe some much better than this suggestion. But I'll bet a few can involve code generation and knowing which areas are 'cheaper' to process.

Anyway stick with what you're doing just now but keep your eyes open for other ways to cut the amount of copying - probably by specializing on a per-sprite, per-tile and per-line basis. Also remember you have 16 words of halftone in the blitter - enough for 1 plane of 1 tile. If the same tile recurs 5 times, then you can load the halftone once, and blit the plane to 5 tiles much quicker. This would speed up the solid backgrounds in RType (but not the starfield backgrounds, admittedly)

Just stuff to think about.

evil
Captain Atari
Captain Atari
Posts: 189
Joined: Sun Nov 12, 2006 8:03 pm

Re: R-Type Deluxe Development Restarted.

Postby evil » Thu Jan 23, 2014 4:52 pm

bod/STAX wrote:I've been thinking a lot about the speed issue with this game over X-Mas and a first and obvious speed up was to take out
all sprite masking in the game just like in the original version of R-Type.


Hi!

I don't think frame dropping is necessarily a bad thing, it can get a game from empty and uneventful to very intense and fun.

I'm not sure if I'm right on this, but I got the feeling in R-Type Deluxe that when it frame skipped, the game logic also skipped ticks so the actual game play slowed down, not just the graphics render. Other great shooters on the ST like Lethal Xcess actually have varying frame rate but the game "motor" keeps ticking at a steady pace, works great in my opinion.

Zamuel_a
Atari God
Atari God
Posts: 1236
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: R-Type Deluxe Development Restarted.

Postby Zamuel_a » Thu Jan 23, 2014 5:08 pm

How do you do the background save / restore? Do you copy the background each time for each sprite or do you have a copy of the entire level in memory so you can grab the data from that one and don't need the save procedure at all. You could multiplex all shots that are on screen since they move so fast so it's not so noticeable that they flicker.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: R-Type Deluxe Development Restarted.

Postby dml » Thu Jan 23, 2014 5:10 pm

evil wrote:I don't think frame dropping is necessarily a bad thing, it can get a game from empty and uneventful to very intense and fun.
I'm not sure if I'm right on this, but I got the feeling in R-Type Deluxe that when it frame skipped, the game logic also skipped ticks so the actual game play slowed down, not just the graphics render. Other great shooters on the ST like Lethal Xcess actually have varying frame rate but the game "motor" keeps ticking at a steady pace, works great in my opinion.


Agree with all of this.

It can require a bit of extra care to keep the 'game motor' properly separate from drawing, but it can help sort out some deeper problems too. Worth the effort.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: R-Type Deluxe Development Restarted.

Postby dml » Thu Jan 23, 2014 5:14 pm

Zamuel_a wrote:How do you do the background save / restore? Do you copy the background each time for each sprite or do you have a copy of the entire level in memory so you can grab the data from that one and don't need the save procedure at all. You could multiplex all shots that are on screen since they move so fast so it's not so noticeable that they flicker.


Yes absolutely. Simplify the execution paths for small things which arrive in big numbers (and give up some drawing accuracy - the smaller and faster they go the less it matters), while optimizing fill area for big things which arrive in small numbers, even if the execution path gets less longer and more complex...

User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2025
Joined: Sun Jul 31, 2011 1:11 pm

Re: R-Type Deluxe Development Restarted.

Postby Eero Tamminen » Thu Jan 23, 2014 7:16 pm

Doing worst frame profiling with Hatari might also find something to improve.

User avatar
bod/STAX
Atari Super Hero
Atari Super Hero
Posts: 508
Joined: Wed Nov 24, 2004 8:13 pm
Location: Halesowen, West Midlands, England

Re: R-Type Deluxe Development Restarted.

Postby bod/STAX » Thu Jan 23, 2014 8:14 pm

Well how would you keep the game "motor" running at a regular pace even when the gfx rendering causes slowdown
if everything is done off a main loop?

If I could get the game "motor" running at a constant regular pace then I think it would help things a lot as I think
this is the main cause of the problem.
So let it be written, So let it be done. I'm sent here by the chosen one.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: R-Type Deluxe Development Restarted.

Postby dml » Thu Jan 23, 2014 8:25 pm

bod/STAX wrote:Well how would you keep the game "motor" running at a regular pace even when the gfx rendering causes slowdown
if everything is done off a main loop?

If I could get the game "motor" running at a constant regular pace then I think it would help things a lot as I think
this is the main cause of the problem.


You can count VBLs, and make sure the 'motor' is executed as many times as VBLs are counted. i.e. you tick the motor in a loop with a count of 1, sometimes 2.

It's important to keep the motor cheap relative to drawing time, or it doesn't work. When it can work, it does help a lot.

User avatar
bod/STAX
Atari Super Hero
Atari Super Hero
Posts: 508
Joined: Wed Nov 24, 2004 8:13 pm
Location: Halesowen, West Midlands, England

Re: R-Type Deluxe Development Restarted.

Postby bod/STAX » Thu Jan 23, 2014 10:10 pm

OK Let me see if I've got this right. The main loop currently looks like this:

Code: Select all

loop:
; Update screen stuff here (sprites, whatever...)

; You gave me this bit of code DML
sync: tst.w vbl_count
      bgt.s sync

      move.w vbl_count,d0 ; sync with top of screen
.l1   cmp.w vbl_count,d0
      beq.s .l1

      move.w #fps,vbl_count ;fps=1 (25 frames)

; now do all other stuff (move player, move aliens, collision detect)
; the game "motor"
      bra loop

vbl_count dc.w 0 ; this is decreased off the vbl


So to get the "motor" to run constantly I should move all that stuff it into the "sync" loop (the tst.w bit) and check that it's
been called once and once only instead if waiting until the next frame afterwards as I'm doing now.

Am I along the right lines?
So let it be written, So let it be done. I'm sent here by the chosen one.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: R-Type Deluxe Development Restarted.

Postby dml » Thu Jan 23, 2014 10:39 pm

bod/STAX wrote:OK Let me see if I've got this right. The main loop currently looks like this:
Am I along the right lines?


You're thinking along the right lines but I would probably write out whats needed logically before making asm code for it, rather than shuffling things around and adding more flags and counters and stuff.

Ideally you want the system to give you the number of 'catchup' ticks needed to keep the motor beating regularly, even if it's only being visited irregularly (every 1, 2 or worse, 3 frames).

e.g. for the 'motor' part, before rendering, you want something like this:

Code: Select all

 move.w elapsed_vbls,d7    ; 0...N ticks behind realtime
 clr.w elapsed_vbls     ; self-synchronize
 bra .start_motor
.continue_motor:
 move.w d7,-(sp)
 bsr tick_motor         ; process all inputs, move all objects / update all state
 move.w (sp)+,d7
.start_motor:
 dbra d7,.continue_motor


..and in your VBL interrupt you want to have:

Code: Select all

 addq.w #1,elapsed_vbls



That's pretty much it. Every time the motor runs, it catches up with the number of VBLs elapsed since last time. You can just add this to what you have and it should go.

You shouldn't need to change anything else (I hope), because the above code is self-synchronizing with the VBL. The fact that you have a separate bit of code which waits for the VBL shouldn't matter. In the end that is just artificial dead time to keep the renderer from tearing.

I might have overlooked something, but I'd start with that. I do recommend though you try to understand whats happening here - because you'll stand a much better chance of making it work properly. Just copying my scribbles may not work if there are hidden details or if it turns out to be sensitive to where it is placed. But the idea is easy to understand and adapt.


One glitch may occur if the VBL happens between reading and clearing the variable 'elapsed_vbls'. This can be fixed by raising the interrupt priority mask around those 2 ops, to simulate an 'atomic operation'. i.e. non-interruptible single operation.

User avatar
bod/STAX
Atari Super Hero
Atari Super Hero
Posts: 508
Joined: Wed Nov 24, 2004 8:13 pm
Location: Halesowen, West Midlands, England

Re: R-Type Deluxe Development Restarted.

Postby bod/STAX » Thu Jan 23, 2014 11:32 pm

Thanks for that.

I'll have a play around with it tomorrow and let you know how I get on.

Bod.
So let it be written, So let it be done. I'm sent here by the chosen one.

User avatar
bod/STAX
Atari Super Hero
Atari Super Hero
Posts: 508
Joined: Wed Nov 24, 2004 8:13 pm
Location: Halesowen, West Midlands, England

Re: R-Type Deluxe Development Restarted.

Postby bod/STAX » Sat Jan 25, 2014 6:27 pm

I've been playing around with the above code in my game and well to be honest things act very
strangely.

I understand what the above code does and is for a game that runs at 50fps. If the code is running
at 50fps 'motor_tick' is called once. If the code drops to 25fps 'motor_tick' is called twice. If
the code drops to 12.5fps 'motor_tick' is called 3 times and so on keeping the 'motor' running regularly
even though the graphical update has dropped.

My game runs at 25fps so as I see it using the above example if 'current_vbls' is incremented every frame
when the frame-rate drops I would have to call 'motor_tick' every other frame.

As things stand the game starts out ok but when the frame-rate drops things start to go weird. It's as if
the game is running on an emulator with automatic frame-skip enabled. It goes from the normal 25fps
to what looks like 10fps when the game normally slows down a bit. I know some tweaking is required to
my routines but surely I should be getting better results than this.
So let it be written, So let it be done. I'm sent here by the chosen one.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: R-Type Deluxe Development Restarted.

Postby dml » Sat Jan 25, 2014 6:33 pm

Hi,

This is an indication of (probably) 2 things going on at once:

1) if your game is framelocked to 25hz, then yes you need to tick 1/2 of the elapsed vbls e.g. (elapsed_vbls / 2) and you need to make sure both measurements start on the same vbl, so they are in sync at the start
2) partly because of this (but maybe also generally) your gametick motor costs more than you think, so the cost of ticking 2 times (or in this case, 4 times!) is adding to slowdown.

So fix the motor ticker so it only ticks once per 25hz interval (every 2 vbls) and retry. If it is still a problem then it cant be used without optimizing your game motor so it takes less time relative to drawing.

[EDIT]

I just realized what you were asking now :-) - since you normally want to tick the motor every 2nd vbl you've got an unfortunate problem at 16Hz (3 vbl intervals) since you need a 'half-tick' and there is no such thing. TBH It would be complex to solve this for your game (a 'full' AI tick, and an 'interpolate' or move-only tick which keeps things moving but not thinking) so it might not be suitable after all. It's *much* easier to do if your fundamental rate is 1 tick per VBL...

User avatar
bod/STAX
Atari Super Hero
Atari Super Hero
Posts: 508
Joined: Wed Nov 24, 2004 8:13 pm
Location: Halesowen, West Midlands, England

Re: R-Type Deluxe Development Restarted.

Postby bod/STAX » Sat Jan 25, 2014 8:54 pm

Obviously dropping a frame from 25fps would indeed make it 3 vbl's which as you said would incure a 'half tick'
which you can't have so, would it be possible to force it to 4 vbl's instead of 3 or would this now require
in impossible 'quater tick'?
So let it be written, So let it be done. I'm sent here by the chosen one.

Zamuel_a
Atari God
Atari God
Posts: 1236
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: R-Type Deluxe Development Restarted.

Postby Zamuel_a » Sat Jan 25, 2014 9:16 pm

Why not run the engine at a fixed speed of 25fps and multiplex the sprites if needed? When you would never have any slowdown at all.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: R-Type Deluxe Development Restarted.

Postby dml » Sat Jan 25, 2014 9:33 pm

bod/STAX wrote:Obviously dropping a frame from 25fps would indeed make it 3 vbl's which as you said would incure a 'half tick'
which you can't have so, would it be possible to force it to 4 vbl's instead of 3 or would this now require
in impossible 'quater tick'?


You could force it to 4 vbls and it will begin to work properly but it might be a bit rough at 4 vbls per refresh for scrolling.

(yes - sorry, when we started talking about the catchup method I forgot we were starting with 2vbls and not 1, and that does make things harder - not impractical but harder)

User avatar
bod/STAX
Atari Super Hero
Atari Super Hero
Posts: 508
Joined: Wed Nov 24, 2004 8:13 pm
Location: Halesowen, West Midlands, England

Re: R-Type Deluxe Development Restarted.

Postby bod/STAX » Sat Jan 25, 2014 9:37 pm

Zamuel_a wrote:Why not run the engine at a fixed speed of 25fps and multiplex the sprites if needed? When you would never have any slowdown at all.


I wanted to try other things before doing multiplexing so now that is going to by my next step.

I will still keep the unmasked sprites with the multiplexing as to keep flicker down to as bare minimum as possible.

Didn't you say in a previous post that you timed the sprites in your game to the number of scanlines each took
and if so how did you do this exactly, or was it a rough timing?

dml wrote:You could force it to 4 vbls and it will begin to work properly but it might be a bit rough at 4 vbls per refresh for scrolling.


I'll have a go at forcing it to 4 vbl's tomorrow and see how thing's turn out.
So let it be written, So let it be done. I'm sent here by the chosen one.

evil
Captain Atari
Captain Atari
Posts: 189
Joined: Sun Nov 12, 2006 8:03 pm

Re: R-Type Deluxe Development Restarted.

Postby evil » Sat Jan 25, 2014 10:50 pm

bod/STAX wrote:Obviously dropping a frame from 25fps would indeed make it 3 vbl's which as you said would incure a 'half tick'
which you can't have so, would it be possible to force it to 4 vbl's instead of 3 or would this now require
in impossible 'quater tick'?


An idea is to run the "motor" at fixed speed on interrupt, like VBL and the render stuff in a main loop.

The VBL code will be 25 Hz always, the render stuff will catch up as good as it can. One problem that can arise is that the VBL updates values halfway into the render, and some sprites/game logic will be out of sync. That's solved by using double buffer values so the VBL is writing stuff to one place and rendering code reads from another.

By doing it like this it's also possible to use triple buffer screens which can improve frame rate a bit as it avoids waiting for VBL after end of mainloop. It costs memory though.

Zamuel_a
Atari God
Atari God
Posts: 1236
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: R-Type Deluxe Development Restarted.

Postby Zamuel_a » Sat Jan 25, 2014 11:35 pm

Didn't you say in a previous post that you timed the sprites in your game to the number of scanlines each took
and if so how did you do this exactly, or was it a rough timing?


Yes to calculate how much CPU time a sprite of a certain size took, I had to do some statistics. I have 4 sprite sizes that I use (16xY, 32xY, 48xY, 64xY) and for each size I draw as many as possible on a certain time period to see how much time they took. It was just a visual check so not 100% perfect, but it works.
For example to see how much time a 16xY sprite takes:

Create some marks on the screen there your sprite test routine will start and another mark further down (for example two horizontal lines. 150 lines apart).
Change the background color at the same time as you turn on the sprite drawing and change it again after all sprites are finished. Then you can see how much CPU time the drawing took and the idea is to fill up the area between the horizontal lines.
So first I tried to draw as many 16x1 sprites as possible during this time frame until my raster color filled my specified area. After that I tried 16x2 sprites, 16x3 and so on until finally I only could draw one sprite that was maybe something like 16x150 or whatever. Now I could see that for each line added in the sprite, it was a constant increase in cpu time, plus a certain constant value that was always there (sprite setup time), so finally I ended up with a simple formula with the exakt time every added line for a sprite of a certain width took and that's what I used in my multiplexer.

The multiplexer itself is very easy. Before I draw my sprite I add the CPU time it will take to a total percentage value. If it's < 100%, I draw it like normal and I also set a flag telling it that it has been drawn. As soon as the total percentage goes > 100% I skip drawing of this sprite and sets the flag that it was NOT drawn.

I actually go through the sprite list twice. First I check the sprites that DIDN'T get drawn in the previous frame and let them get drawn first and after that I take the rest, so this will handle unlimited number of sprites without you thinking about it.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: R-Type Deluxe Development Restarted.

Postby dml » Sun Jan 26, 2014 10:44 am

A few more notes:

1) Evil's method is ideal for variable framerates, but best for scrolling when scrolling is 2vbls or greater. It doesn't guarantee perfect scroll-sync which might be noticed at the top speed of 1 vbl, if that speed is reached. It does however have one big advantage - it uses every clock cycle with 100% efficiency and your game uses 2 vbls normally, making it the best choice IMO.

Note: while it can depend on 3 framebuffers to stop tearing, IIRC it can run with only 2 providing it doesn't run faster than 1 vbl (or is it 2? i don't remember now - but it runs fine with 2 buffers beyond some magic vbl count, probably 1)

2) Zamuel's method is better if you must run in 1 vbl, and (very cleverly) turns the ST into a constant-time machine, for drawing at least. It is however much harder to use all cycles with 100% efficiency, esp. since it does not multiplex the work in the motor tick too. So it benefits from a flat (low) cost in the game motor. This depends a lot on the game. So I think this is more ideal for 1-vbl games with simple AI which depend on perfect scroll-sync.

For *your* game I'd probably start with Evil's method and perhaps move to Zamuel's if scrolling is visibly jumping or you get tearing and can't afford a 3rd framebuffer.


3) You can still do a working experiment with my original (very simple) suggestion by implementing the 'half tick'. Just tick 1/2 of all objects on odd visits, and the other half on even visits. You'll then get 1.5 ticks for 3 elapsed vbls as required (instead of 3 ticks, which is what you got in the first test with my change - or 1 tick which is what you get without adaptations).

I recommend this only if its easy to divide the main work in half. If you have other fixed overheads which contribute a lot to time and it's hard to divide those in two - don't bother. Cut straight to one of the other two methods above. Even if it is easy to do, treat it as exploratory - it's still better to do a bit of work and adopt (e.g.) Evil's method for the sake of efficiency etc.

Have fun figuring out what to do :)

Zamuel_a
Atari God
Atari God
Posts: 1236
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: R-Type Deluxe Development Restarted.

Postby Zamuel_a » Sun Jan 26, 2014 12:01 pm

Yes my routine is best if you have full control of the timing for everything. In my game I have timed everything to run in 1 vbl and the only drawing time for sprites are in the borders so the time is fixed and easy to multiplex. But I think it should be possible to use it to run at a constant speed of 25fps to. You need to find the time the game motor runs at in worst case to see how much CPU time you have left.

Maybe it could be possible to calculate the time the game motor takes by checking the video counter? If you read the video counter just before the motor starts and at the end, then you know how much CPU time it took and can calculate how much time you have left for sprites.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe


Social Media

     

Return to “Games - General”

Who is online

Users browsing this forum: No registered users and 3 guests