Tinyus Tech

[ross]

Originally Posted by pink^abyss

Yeah, especially Bartmans GCC11 compiler is efficent enough. However, often it does not matter so much if C or ASM is used but what your algorithms are. In asm projects you often tend to micro optimize, while in C projects you simply try another algorithm.

Wait! GCC11? There is a version based on GCC Development somewhere?

[pink^abyss]

Originally Posted by ross

Wait! GCC11? There is a version based on GCC Development somewhere?

No, i was wrong. Its version GCC10.1!

[Jobbo]

Documentation says it’s GCC10.1

Don’t know what difference that makes but it is excellent!

[ross]

Originally Posted by pink^abyss

- the restore buffer is always a 'splitted' buffer

Not if you add one more buffer to the 'roll'.

At first I thought you also used an infinite y-corkscrew technique for buffers, then looking at your code and seeing that you used separate buffers I realized that you only do it on x

[pink^abyss]

Originally Posted by ross

Not if you add one more buffer to the 'roll'.

At first I thought you also used an infinite y-corkscrew technique for buffers, then looking at your code and seeing that you used separate buffers I realized that you only do it on x

You should make a demo Ross for the 3 or 4 buffer method.. i'm still not sure if this is really working together with x+y scroll

[pink^abyss]

Originally Posted by pink^abyss

You should make a demo Ross for the 3 or 4 buffer method.. i'm still not sure if this is really working together with x+y scroll

After thinking again i'm confident it should be working, but you need to update always 3 buffers at once to scroll.

[ross]

Originally Posted by pink^abyss

You should make a demo Ross for the 3 or 4 buffer method..

I add it to the mountain of unfinished stuff I already have

[aros-sg]

vertical/horizontal swapped here for easier illustration:

Looking just at one of the buffers inside the master buffer:

 ABCDEF............
_BCDEFG...........
__CDEFGH..........
___DEFGHI.........
____EFGHIJ........
_____FGHIJK.......
______GHIJKL......
_______HIJKLM.....
________IJKLMN....
_________JKLMNO...
__________KLMNOP..
___________LMNOPQ.
____________MNOPQR
S____________NOPQR
ST____________OPQR
STU____________PQR
STUV____________QR
STUVW____________R
STUVWX____________
_TUVWXY___________
__UVWXYZ__________

The other 2 buffers are the same but offset/nested in between and use the area not used by buffer1.

 ABCDEFABCDEFABCDEF

You would have some gaps between the buffers

 ABCDEF..ABCDEF..ABCDEF..

unless maybe you have a game which only ever scrolls
vertically and only down like a typical vertical shooter (you need that anyway for horizontal scrolling).
For direction changes to avoid that one buffer trashes over another buffer.

Theoretically it may be possible to scroll the master buffer as a whole (instead of treating the 3 buffers
like normal independant buffers) similiar to the mirror/double height scrolling (except triple height), but
that may complicate BOB restoring, if at the time of the restore the "view position" is no longer the same
as at the time the BOBs were blitted.

The master buffer height likely will need to be 3 * height + extra_tilerow high (== wrapping also happen at that
Y position), because otherwise during direction change (maybe one could away if for Y-direction change one extra
frame with 0 Y-scrolling is enforced, so -1 to 1 is not possible, instead -1 to 0 to 1)) it may be that there is
a case (even if unlikely and hard to "trigger") where not just one buffer crosses the wrap line, but two of them.


So with this you have 2 buffers which should never be wrapping, and 1 which almost always will be wrapping.
If you want 3 non-wrapping buffers then you would need 4 buffers in a 4*height+extraheight masterbuffer.

The buffer which is wrapping changes as you scroll around, so the roles of the buffers must be changed from time
to time, ie. change the current backbuffer to the restorebuffer and the restorebuffer to the backbuffer. This
should be possible, because after BOB restoration restore buffer should be and look like backbuffer.

[aros-sg]

Originally Posted by pink^abyss

After thinking again i'm confident it should be working, but you need to update always 3 buffers at once to scroll.

No, they can be treated like individual buffers that just happen to use the space inside the masterbuffer which is currently unused by the other buffers. So they also move around in memory a bit similar to how buffers move around (or up and down) in memory during horizontal scrolling.


One thing to be careful with is that unlike with really 100% separate buffers (which do not share space inside a master buffer) one must make sure that one individual buffer's view (scroll) position is never very far apart from the other buffers' view position. To avoid that they trash/trample over each other.

[Antiriad_UK]

I need to go and read that corkscrew scrolling doc on aminet as I don’t have a scooby what is going on here

[zero]

How did you rip all the assets from the original game? I'm mostly interested in the game logic, if you recreated it or did a more direct conversion of the 68k code from the arcade.

I've been looking at reverse engineering a couple of games, Sidewinder for the Amiga and Midnight Resistance for arcade. It's been so long since I was actively working on 68k assembler and I need to investigate what tools can be used to reverse engineer the game engines.

[pink^abyss]

Originally Posted by aros-sg

No, they can be treated like individual buffers that just happen to use the space inside the masterbuffer which is currently unused by the other buffers. So they also move around in memory a bit similar to how buffers move around (or up and down) in memory during horizontal scrolling.

I talked about the 4 buffers method. I think there you need to blit into 3 buffers each frame to make it work. You need to blit to one of the backbuffers, to the current restore buffer, and to the future restore buffer.
With 3 buffers and splitted restore you would need only 2 blits.

[pink^abyss]

Originally Posted by zero

How did you rip all the assets from the original game? I'm mostly interested in the game logic, if you recreated it or did a more direct conversion of the 68k code from the arcade.

I've been looking at reverse engineering a couple of games, Sidewinder for the Amiga and Midnight Resistance for arcade. It's been so long since I was actively working on 68k assembler and I need to investigate what tools can be used to reverse engineer the game engines.

Reverse engeneering was done by Bartman in Mame. He wrote lua scripts to extract all the gfx. As these can't be used in amiga due to the palette swapping we created from this base the amiga gfx.

[zero]

Originally Posted by pink^abyss

Reverse engeneering was done by Bartman in Mame. He wrote lua scripts to extract all the gfx. As these can't be used in amiga due to the palette swapping we created from this base the amiga gfx.

Did you re-use the 68k code from the arcade or did you figure out the data formats for things like spawning enemies and enemy behaviour?

[Bartman]

no code was reused, but I reverse engineered the level "script" files (object placement) and we used them. also the music was reverse engineered and exported to FT2 files as a base for Pink.

[pink^abyss]

Originally Posted by zero

Did you re-use the 68k code from the arcade or did you figure out the data formats for things like spawning enemies and enemy behaviour?

All code was newly written. The arcade code would have been much too slow. On A500 i estimate you have around 20% of the CPU time the arcade has available. The arcade does things like fixed point float emulation for every object and O^N collision checks for everything. Also the music driver runs on a seperate processor. Scrolling and sprites take almost no time as there is dedicated hardware for it. Still the arcade has only time to update half of the stationary objects each frame. These objects also always lag one frame behind the scrolling.

[pink^abyss]

Originally Posted by Bartman

no code was reused, but I reverse engineered the level "script" files (object placement) and we used them. also the music was reverse engineered and exported to FT2 files as a base for Pink.

The FT2 songs had 6 channels and were reduced to 3 channels in 8bitBubsys FT2 clone (thanks!). Then they were saved to ProTracker format and then this whole mess was imported to PreTracker. Then i ran Pretracker-optimizer over the patterns to remove duplicates. Then i cleaned the songs further and tried make these 3 channel version to sound like the original 6 channel versions. For me, these new versions have some kind of 'PC-Engine' feeling due to the new instruments timbres

[zero]

Interesting, thanks. I guess it will depend on the game, if there is a decent scripting system for doing enemy attack patterns then you might as well use that data.

In other games I've seen code used to do that sort of stuff, like each enemy has a subroutine that is called which controls it. From what I read most conversions back in the day didn't have access to the source code and didn't attempt to reverse engineer the ROMs, they just made the game behave kinda like what they saw when playing the game. It was annoying because you couldn't use the tips from magazines in your version of the game!

The music is excellent. I'm still so impressed by how much you have moving on screen. I really thought that it was beyond the capabilities of the OCS hardware to do that.

[pink^abyss]

Here some more 'simple' Tinyus Tech infos:

Blitting:
There are two kinds of blits

1. Custom width
A few blits in the game have custom width. For instance the 'Big Core' boss.
They use a flexible and therefore slow blitter routine that handles X&Y clipping, with or without mask etc.

2. Fixed width
- There are two containers, for fast 16 or 32 pixel width masked blits
- To minimize blitter setup all blits of one width are blitted after another, so you must decide if you want all 32 width blits in fronts or all 16 width blits
- Height is variable for each blit
- Blitsize register is cached for each blit
- To save cpu time these blits are only clipped on Y axis. On X axis the bitmaps are 32 pixel wider each line and have a 32 pixel offset on start. So no clipping is needed on X axis.

Memory Handling:
- All needed chip and other ram is taken on start from the OS
- A Frameheap manages this ram. If a game part is done then the frameheap is reset to its previous state. Simple and fast.
- A number of Unitheaps are used to manage all ingame objects. The different objects are enemies, player shots, enemy shots, player lasers, explosions and collectibles.
- Each of the unit heap has a fixed amount of items it can hold

Game logic:
Most things, like game parts, enemy movement etc. are managed with state machines. For the more advanced state machines its mandatory to call a setState(newState) function to change a state. This is flexible enough to make all kind of later adjustments possible.
At any level x scroll offset also functions can be invoked which then run in with the other code. So any special stuff can be added dynamically to the game logic without polluting the normal code base.

Enemy logic:
All enemy movement is coded, not tabled. That is because most enemies react to the player position in subtle ways. Thats also the reason that Gradius still feels fresh in comparison to many other shmups from that era.

Background stars:
These are done with one sprite in 3 different colors and 4 different speeds. To process them more quickly a 70kb table is created on startup. This was around 2 times as fast as moving them by code along. In the last level these stars are hidden as soon as the 2nd background layer appeared fully.

Endpart:
The zooming of the space station is done with the blitter in realtime. Nothing fancy, and also not running in full frame rate on A500. The arcade version on the other side is much worse looking despite having zoom hardware available.

[zero]

Originally Posted by pink^abyss

2. Fixed width
- There are two containers, for fast 16 or 32 pixel width masked blits
- To minimize blitter setup all blits of one width are blitted after another, so you must decide if you want all 32 width blits in fronts or all 16 width blits
- Height is variable for each blit
- Blitsize register is cached for each blit
- To save cpu time these blits are only clipped on Y axis. On X axis the bitmaps are 32 pixel wider each line and have a 32 pixel offset on start. So no clipping is needed on X axis.

It feels like this is one of the most important parts of the code, the reason why you are able to get so much on screen. The blitter can do so much if handled right, but I don't think many games came close to this level of performance.

Memory Handling:
- All needed chip and other ram is taken on start from the OS
- A Frameheap manages this ram. If a game part is done then the frameheap is reset to its previous state. Simple and fast.
- A number of Unitheaps are used to manage all ingame objects. The different objects are enemies, player shots, enemy shots, player lasers, explosions and collectibles.
- Each of the unit heap has a fixed amount of items it can hold

Interesting! How are you managing allocations? A lot of games just used arrays, but of course then every object has to be fixed size.