English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   Coders. General (http://eab.abime.net/forumdisplay.php?f=37)
-   -   Line of Fire Question (http://eab.abime.net/showthread.php?t=93080)

sandruzzo 20 June 2018 11:25

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

zero 20 June 2018 12:48

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.

sandruzzo 20 June 2018 14:41

So isnt' real time?

Shatterhand 20 June 2018 22:20

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.

dlfrsilver 21 June 2018 00:50

Quote:

Originally Posted by Shatterhand (Post 1249492)
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 ;)

zero 21 June 2018 09:58

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.

britelite 21 June 2018 11:07

Quote:

Originally Posted by dlfrsilver (Post 1249517)
The board use a 21 millions of colors palette.

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

sandruzzo 21 June 2018 11:29

Quote:

Originally Posted by zero (Post 1249553)
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.

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

dlfrsilver 21 June 2018 12:46

Quote:

Originally Posted by britelite (Post 1249569)
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'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.

britelite 21 June 2018 12:53

Quote:

Originally Posted by dlfrsilver (Post 1249582)
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'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:
Quote:

I've worked out the graphic format of this sega system, and it uses shit tons of colors.
Alright, show me the specs of this format :)

Daedalus 21 June 2018 13:16

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?

dlfrsilver 21 June 2018 14:43

Quote:

Originally Posted by britelite (Post 1249585)
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 :)

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.

dlfrsilver 21 June 2018 14:44

Quote:

Originally Posted by Daedalus (Post 1249590)
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?

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.

britelite 21 June 2018 15:08

Quote:

Originally Posted by dlfrsilver (Post 1249609)
The specs ?

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

Quote:

the proof : I have extracted most of all shinobi arcade graphic assets. and also some others like Hang-on and Super Hang On.
Ok, then show me how the "21 million" colours are defined in those graphics assets.

Quote:

They were remapped from 21 million to 16 colours by Andy Heike, Nick Vincent, and some students in Manchester.
But still, you're not answering where you get that "21 million" figure from.

EDIT:
Quote:

The bitmap graphics were grabbed from the arcade PCB video output by Andy Heike and Nick Vincent with the colour frame grabber
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.

dlfrsilver 21 June 2018 21:53

Quote:

Originally Posted by britelite (Post 1249614)
The specs of the graphics format you claim to have extracted.

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.

Quote:

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

britelite 22 June 2018 08:04

Quote:

Originally Posted by dlfrsilver (Post 1249742)
Ok, even in mame, if you take a screenshot, you'll get it in millions of colors as well.

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.

Quote:

when a game uses 100.000 colors, you must use the 16 millions colors mode at least.
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)?

sandruzzo 22 June 2018 08:05

Line of Fire Amiga version use prescaled "bob"?

britelite 22 June 2018 08:21

Quote:

Originally Posted by sandruzzo (Post 1249823)
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 :)

dlfrsilver 22 June 2018 09:05

Quote:

Originally Posted by britelite (Post 1249821)
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)?

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.

britelite 22 June 2018 09:09

Quote:

Originally Posted by dlfrsilver (Post 1249828)
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.


All times are GMT +2. The time now is 13:24.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.

Page generated in 0.04607 seconds with 11 queries