RESHOOT PROXIMA III – New game from the RESHOOT R guys

[Chrille]

Originally Posted by roondar

Interesting, dynamic frame rate for bobs. Don't remember games doing this - only games that either stuck to 50FPS or stuck to 25FPS (or even lower) for bobs. Nice stuff!

This is not a new technique on Amiga. But it is too less used! And it is easy to implement on a new game engine. Also this is a cool feature for supporting better CPUs and hardware, so a jerky OCS game could run smooth on AGA.

SWIV was the first Amiga 2D-action game (at least the first game I saw) with dynamic frame rate, but SWIVs best frame rate was only 25 FPS (it could slow down to something like 10 FPS). Also most of 3D games have a dynamic frame rate. And Battle Squadron was the first game I saw which has a mixed frame rate (Sprites and Scrolling @50FPS, BOBs@25FPS)

Looking forward to Reshoot Proxima III

[buzzybee]

Originally Posted by Chrille

This is not a new technique on Amiga. But it is too less used! And it is easy to implement on a new game engine. Also this is a cool feature for supporting better CPUs and hardware, so a jerky OCS game could run smooth on AGA.

SWIV was the first Amiga 2D-action game (at least the first game I saw) with dynamic frame rate, but SWIVs best frame rate was only 25 FPS (it could slow down to something like 10 FPS). Also most of 3D games have a dynamic frame rate. And Battle Squadron was the first game I saw which has a mixed frame rate (Sprites and Scrolling @50FPS, BOBs@25FPS)

Looking forward to Reshoot Proxima III

Dynamic framerate is common with 3D-games, yes. I cannot remember a single 2D-game though, which mixes steady 50fps for scrolling plus sprites with dynamic drawrate for bobs. Proxima 3 aims for 50fps for bob updates too. But in very busy situations this may drop to 25fps.

The trick is: Movement of all onscreen objects is updated at 50 fps no matter what. Sprites and scrolling keep a steady 50fps too. The bob drawing code is not synced though and may be 50fps, 25fps or 20fps. This means player vessel, bullets, all objects keep their momentum all the time, regardless of the density of onscreen action.

Actually I, too, thought it´d be easy to implement such a dynamic drawing thingy on Amiga. But real life taught me otherwise. I found it pretty challenging and also relieving when it finally worked.

[sandruzzo]

What about some sort of Variable shading Rate? Like object in focus will run at 50hz others at 25 and 17fps the more the distance, less the rate..

[buzzybee]

Originally Posted by sandruzzo

What about some sort of Variable shading Rate? Like object in focus will run at 50hz others at 25 and 17fps the more the distance, less the rate..

Interesting proposal, might be very useful under certain circumstances. You want to open a new thread in Coders.general before D Bossmod steps in and closes / moves this thread (again)?

[Chrille]

Originally Posted by buzzybee

Dynamic framerate is common with 3D-games, yes. I cannot remember a single 2D-game though, which mixes steady 50fps for scrolling plus sprites with dynamic drawrate for bobs. Proxima 3 aims for 50fps for bob updates too. But in very busy situations this may drop to 25fps.

Yes, I remember also only my old unreleased game engine from 1995 There are too less games with 50 FPS. But the technique is old. SWIV fails at running with 50 FPS, but it is the same technique. And yes, you are right, this will be the first released game with 50FPS for sprites and scrolling and a variable frame rate for BOBs.

Originally Posted by buzzybee

The trick is: Movement of all onscreen objects is updated at 50 fps no matter what. Sprites and scrolling keep a steady 50fps too. The bob drawing code is not synced though and may be 50fps, 25fps or 20fps. This means player vessel, bullets, all objects keep their momentum all the time, regardless of the density of onscreen action.

Actually I, too, thought it´d be easy to implement such a dynamic drawing thingy on Amiga. But real life taught me otherwise. I found it pretty challenging and also relieving when it finally worked.

Yes, you have to keep 3 Positions, one postion for the current position, and two others for you double buffered screen. And when you have something like a linked list, you must also watch out not destroy your structure. E.g. you can not always delete items from your list. Instead mark it as deleted and delete it when it is safe.

And yes the theory is always easier than the implementation. I remember a implementation of double linked list in C++. This should not be too hard to implement, but the number of bugs showed me something different.

[buzzybee]

Had to bughunt for a few weeks, but finally got that little jerk. Wrote a bit of text about the bughunt – it´s on Patreon but it´s still free, so please y´all check it out!

[Gilbert]

Since you guys are talking tech - is there ever any need to triple-buffer games? I always wondered what the point of that would be??

I remember Andrew Braybrook saying he tried it on Fire and Ice to start with.

[roondar]

Depends on what you mean by triple-buffer. I've used a third buffer that only contained the background many times to accelerate blitting. But I've never used three buffers to actually draw to in sequence.

Standard triple-buffering could still be useful if you have an unsteady frame rate though. Using three buffers in the traditional sense (drawing&displaying in sequence) allows you to smooth out the frame rate at the expense of latency.

[buzzybee]

Originally Posted by roondar

Depends on what you mean by triple-buffer. I've used a third buffer that only contained the background many times to accelerate blitting. But I've never used three buffers to actually draw to in sequence.

Standard triple-buffering could still be useful if you have an unsteady frame rate though. Using three buffers in the traditional sense (drawing&displaying in sequence) allows you to smooth out the frame rate at the expense of latency.

For RESHOOT R (and Proxima 3) I use three buffers, switching between each of them and blitter-restoring background from the one which is currently in "idle" state. So yes, this technique speeds up blitter-objects quite a lot.

[Gilbert]

Originally Posted by roondar

Depends on what you mean by triple-buffer. I've used a third buffer that only contained the background many times to accelerate blitting. But I've never used three buffers to actually draw to in sequence.

Standard triple-buffering could still be useful if you have an unsteady frame rate though. Using three buffers in the traditional sense (drawing&displaying in sequence) allows you to smooth out the frame rate at the expense of latency.

Yes i was thinking of the standard version you mention. Just thinking about it in my head - it never really seems worth it. Once you drop a couple of frames it doesn't seem you are any better off than with double buffering.

[Tigerskunk]

You save the time for the 'save'-blit.
Speeds up blitter stuff a lot..

[roondar]

Yeah, it's a big win. Costs quite a bit of memory though, which is a bit painful on OCS machines.

[buzzybee]

I am adding narrative elements to the shmup action. The screenshot shows a test case of my approach; also the first glimpse of the beautiful hero and antagonist portraits which Rod March created. Should add some kind of purpose to the whole game, make you feel more proud of your accomplishments.

What do you guys think when you see this?

[Tsak]

Nice! I loved that Reshoot-R also had a similar mini story going on. But I hope this time that the portraits will be treated better. The super dithered portraits of Reshoot-R felt really out of place compared to the -otherwise- pretty neat overal artwork.

[buzzybee]

Originally Posted by Tsak

Nice! I loved that Reshoot-R also had a similar mini story going on. But I hope this time that the portraits will be treated better. The super dithered portraits of Reshoot-R felt really out of place compared to the -otherwise- pretty neat overal artwork.

I feel you. This time, each portrait will have its own dedicated palette / does not need to share its colors with the game-view as in RESHOOT R. Therefore color quality will be much better.

[Marchie]

Lookin' sweet

[thairacerjp]

yeah it's really gorgeous colorful now and really love the background artwork of each side of the screen, deadly ambiance , really emphasizing the atmosphere , thankfully you had a save and not lost this awesome progress, I believe that making a game like this is not a bed of roses ! keep the good work

[wairnair]

I had plenty of fun with the prequel, interested in this one too. Looks great so far. Do you have a release date estimate? Would be great to play this summer..

[thairacerjp]

Originally Posted by wairnair

I had plenty of fun with the prequel, interested in this one too. Looks great so far. Do you have a release date estimate? Would be great to play this summer..

he said the game was about half complete, so i don’t expect for this summer,
end of year or 2021, it’s a hard work with great content, so let time to go , Richard is a perfectionist ! , remember reshoot -r was very long to .

[buzzybee]

Originally Posted by wairnair

I had plenty of fun with the prequel, interested in this one too. Looks great so far. Do you have a release date estimate? Would be great to play this summer..

This summer is out of the question, so sorry. I´d share @thairacerjps estimate of availability. If all goes well, the game should make a end-of-2020 release.