Line of Fire Question
 

Can someone know how did they were able to do zooming on Amiga?:banghead

I think it just uses multiple pre-scaled copies of the sprites. The scaling certainly isn't very smooth.

That's how most Amiga games did scaling.

So isnt' real time?

The arcade game is real time. Pretty sure amiga is Just pre-scaled images.

Richard Aplin said in a thread here how when he received the arcade board to port the game to the ST and Amiga he just laughed as the arcade board is like ten times more powerful than an Amiga.

It's basically a Powerfull PC with 2 68000 running at 12.5mhz and custom FPU chips able to perform Multiplications and divisions (called hardware multiplier and divider).

The board use a 21 millions of colors palette.

Source : me, as i own the arcade board ;)

Pre-scaled sprites were the standard way of doing this sort of thing, e.g. for racing games like Hang On and Outrun.

The Amiga can do some scaling by spamming the scroll register, but it only works on bitmaps and entire scanlines.

You counted all the colors yourself? ;)

As in, I don't buy this claim. Other sources says it has 15 bit colors + 1bit shadow/highlight, which would give you almost 100k colors, but nowhere near 21 million

I think if you scale well the entire bitmap you can archive a good scaling effect in y direction, the problem is x direction

I'm not joking. I put my hands on the sega system, and indeed, Line of Fire has a global palette of 21 million of colors !

I've worked out the graphic format of this sega system, and it uses shit tons of colors.

that's also what Richard Aplin has discovered during the conversion.

Basically, Line of Fire graphics have been done on a big PC system called The Sega digitizer III.

the particularity of this system is that the graphics were made on a custom version of Autocad (the famous graphic drawing tool).

shinobi, golden Axe, altered beast, most famous Sega titles on sega system have been drawn on autocad.

I'm sure you're not joking, but I still don't buy it. I do want some proof of this claim, as 21 million colors doesn't make any sense.

Wikipedia says the Sega X Board the games is based on has a color palette of 98,304 colors. Same goes for https://segaretro.org/Sega_X_Board

So I'm really interested where you get your numbers from, as I'm more inclined to believe the specs I referenced than your random numbers.

EDIT:
Alright, show me the specs of this format :)

Yep, for that sort of palette to make any sense, it first off needs to be using more than 24 bits per pixel, which even today isn't used on top-end games (Remember that a 32-bit colour mode still only includes 24 bits of color data, which is ~16.8 million colours). So perhaps it's using some sort of hardware offset scheme like HAM on the Amiga, and a non-RGB colour system... But even that wouldn't make any sense - why bother going to such lengths to introduce colours that probably can't be perceived by the naked eye?

I also wonder about the AutoCAD element - it's a hideous tool for drawing computer graphics. Are you sure it wasn't just a part of the processing, for example as part of the digitizer setup, in which case the graphics were drawn on paper and then scanned in to produce a vector version, which could then be scaled to suit different resolutions?

The specs ? The sega system boards, whatever they are are basically mixing Planar tiles with chunky bitmap graphics.

those chunky bitmap graphics can be sprites, background or scene parts.

the proof : I have extracted most of all shinobi arcade graphic assets. and also some others like Hang-on and Super Hang On.


richard himself said this :

"The bitmap graphics were grabbed from the arcade PCB video output by Andy Heike and Nick Vincent with the colour frame grabber, and the sprites were read, decoded and converted from the arcade machine's Eproms by me. (Not a bit of bloody help from Sega either!)

They were remapped from 21 million to 16 colours by Andy Heike, Nick Vincent, and some students in Manchester.

I guess Sega got a custom version of AutoCAD. I found this information in a twitter like site, showing japanese development machines, and where this information has been given by a Sega arcade engineer.

The specs of the graphics format you claim to have extracted.

Ok, then show me how the "21 million" colours are defined in those graphics assets.

But still, you're not answering where you get that "21 million" figure from.

EDIT:
This of course might explain why you seem to think the hardware handles more colors than it does, as the video output will have artifacts resulting in more colors. For example, a C64 handles and outputs 16 colors but the video signal will have way more due to composite artifacts.

The specs ? Chunky bitmap (read : PC pixel image format), arbitrary size as opposed to the planar tiles 8x8 also used by the boards.

Ok, then show me how the "21 million" colours are defined in those graphics assets.

But still, you're not answering where you get that "21 million" figure from.

Ok, even in mame, if you take a screenshot, you'll get it in millions of colors as well.

This because the only mode able to support the amount of colors is this one.

when a game uses 100.000 colors, you must use the 16 millions colors mode at least.

Indeed, because it always takes a screenshot in truecolor, just like pretty much any other emulator. Doesn't mean the hardware it's emulating handles this amount.

Exactly. When the hardware emulated uses ~17bit colors, you can't replicate that properly with indexed modes or 15/16bit hicolor modes.

Anyway, any of this doesn't explain where you get your random "21 million" colors from. So if you're still going to stick to your claim, it would be easier to take you serious if you back your claim up with some proof (as in technical specifications supporting your claim)?

Line of Fire Amiga version use prescaled "bob"?

It's hard to say, considering the movement seems to be linear, it could very well be possible that the scaling is done "realtime", as in the next step is being calculated offscreen (for the duration of several frames) while moving the previously scaled version on screen. This would at least conserve some memory contrary to having all steps in memory at once.

But I didn't code it, so this is just an educated guess :)

Mame doesn't support as you noticed the tilemaps or any other game graphics in chunky format.

You can only access the planar parts with the F4 key.

This has absolutely nothing to do with what I said.