Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: Digiman on January 06, 2011, 11:02:05 PM
-
I've never seen Wolfenstein 3D run on a stock Amiga, suspect if it even exists it is not full screen (320x200 NTSC not PAL 320x256 full screen).
And how did I come to this conclusion? Well simple. Search out a little game by Domark called Battle Frenzy/Bloodshot for the Sega Megadrive...a machine with no blitter and just powerful sprites/scrolling hardware via a 7.5mhz 68000 CPU with DMA channels just like an Amiga. Of course I presume it has no DSP in the cartridge because it is not one of the ultra rare DSP games for that system unlike the pathetic lump of shit by Nintendo which needed a DSP even for launch games like Pilot Wings :roflmao:
So if anyone knows where Wolfenstein 3D in full screen engine is for Amiga 500 please point me towards it :)
Now interestingly if this game engine can be ported to Amiga 500 (it's 68k code after all) then you should be able to easily do a passable and FAST Doom full screen in 32 colours too with the extra CPU grunt of a stock 2mb Amiga 1200. All that's different is the textured floor and wall superficially. Doesn't have to be perfect but it would be better than anything else I've seen on AGA running on a stock A1200 really.
You tube it, you will be impressed.
*zips up flame proof jacket VERY tightly*
-
I've never seen Wolfenstein 3D run on a stock Amiga, suspect if it even exists it is not full screen (320x200 NTSC not PAL 320x256 full screen).
And how did I come to this conclusion? Well simple. Search out a little game by Domark called Battle Frenzy/Bloodshot for the Sega Megadrive...a machine with no blitter and just powerful sprites/scrolling hardware via a 7.5mhz 68000 CPU with DMA channels just like an Amiga. Of course I presume it has no DSP in the cartridge because it is not one of the ultra rare DSP games for that system unlike the pathetic lump of shit by Nintendo which needed a DSP even for launch games like Pilot Wings :roflmao:
So if anyone knows where Wolfenstein 3D in full screen engine is for Amiga 500 please point me towards it :)
Now interestingly if this game engine can be ported to Amiga 500 (it's 68k code after all) then you should be able to easily do a passable and FAST Doom full screen in 32 colours too with the extra CPU grunt of a stock 2mb Amiga 1200. All that's different is the textured floor and wall superficially. Doesn't have to be perfect but it would be better than anything else I've seen on AGA running on a stock A1200 really.
You tube it, you will be impressed.
*zips up flame proof jacket VERY tightly*
Citadel is a Wolf-3d like game that'll run on an A500 with 1mb RAM (if that counts as "stock").
(Also, Wolf3d is available for both the Apple II/GS and the Atari 800! :D )
-
Nah, that would be impossible, the a500 is totally underpowered.
The following videos might be shocking to some people...
http://www.youtube.com/watch?v=n_ODNdKanGc
http://www.youtube.com/watch?v=DuZywAxfGkw
;)
-
http://www.youtube.com/watch?v=TH9MU6NO-FU
Check that video out, it is the Wolfenstein engine to all intents and purposes really. Neither Megadrive/Genesis has any extra hardware beyond the 7.???mhz 68000 cpu to help render the graphics so why is it possible on the Sega and not on Amiga. Different game but the engine is very similar. Just like Lotus 2 + hacked graphics = dirty port of Outrun for Amiga.
(1mb is fine, even today a 1mb upgrade for Amiga 500s cost peanuts on ebay and there were a fair number of 1mb only games even early on like Dungeon Master)
-
And how did I come to this conclusion? Well simple. Search out a little game by Domark called Battle Frenzy/Bloodshot for the Sega Megadrive...a machine with no blitter and just powerful sprites/scrolling hardware via a 7.5mhz 68000 CPU with DMA channels just like an Amiga. Of course I presume it has no DSP in the cartridge because it is not one of the ultra rare DSP games for that system unlike the pathetic lump of shit by Nintendo which needed a DSP even for launch games like Pilot Wings :roflmao:
The major difference is the tile vs bitmap, so it wouldn't be easy to just port it.
The trick of having the bottom of the screen being a mirror image of the top would be easy with a copper list though.
Lack of sprites might be a problem for bullets, enemies, barrels & weapons. You may have to use dual play field for that or not use a copper list for the mirroring and just copy the data twice (either with the cpu or the blitter).
S.F: Bloodshot is one of the only 3d games for the Megadrive. How powerful was the Megadrive when it came to doing 3D games?
J.B: Not at all. It is a bodge based on the character-based hardware. You had about enough characters to uniquely map about a third of the screen. The ‘polygons’ were inspired by the Wolfenstein 3D approach, they are all made from vertical strips. You might notice that the walls are effectively ‘reflected’ about the centre line using the character map. This is so only half of the walls actually needs to be drawn. I used a palette effect to disguise the reflection, and sprites for the ceiling light to further hide it. The rasterisation was done with about 750K of pre-generated code in order to reduce the cycle-time per pixel and to draw it all in time. It was quite an innovative effect in my opinion, and as you say it is fairly unique to have 3D on the Megadrive.
-
Nah, that would be impossible, the a500 is totally underpowered.
The following videos might be shocking to some people...
http://www.youtube.com/watch?v=n_ODNdKanGc
http://www.youtube.com/watch?v=DuZywAxfGkw
;)
Doom port exists for the Spectrum too....essentially 1bit graphics though :eek:
The A8 port of Wolf is not really finished, there is no allowance for game code, and I believe it is using some weird 80x80 pixel screen mode. Looks good though, hope they have enough CPU time to make it into a game and it isn't another let down like the Shadow of the Beast rolling demo coded for the 128k Amstrad 8bit computers which can never be used for a game.
-
The major difference is the tile vs bitmap, so it wouldn't be easy to just port it.
The trick of having the bottom of the screen being a mirror image of the top would be easy with a copper list though.
S.F: Bloodshot is one of the only 3d games for the Megadrive. How powerful was the Megadrive when it came to doing 3D games?
J.B: Not at all. It is a bodge based on the character-based hardware. You had about enough characters to uniquely map about a third of the screen. The ‘polygons’ were inspired by the Wolfenstein 3D approach, they are all made from vertical strips. You might notice that the walls are effectively ‘reflected’ about the centre line using the character map. This is so only half of the walls actually needs to be drawn. I used a palette effect to disguise the reflection, and sprites for the ceiling light to further hide it. The rasterisation was done with about 750K of pre-generated code in order to reduce the cycle-time per pixel and to draw it all in time. It was quite an innovative effect in my opinion, and as you say it is fairly unique to have 3D on the Megadrive.
Ahh ok yes, tile graphics make a big difference, it's why Powerdrift on the C64 is more impressive than the Amiga port (which is an ST-port anyway)
-
After looking at those vids, I'd reckon none of them would be worth bothering about trying to convert them to the Amiga... just more of the same old stuff that's already available for the miggie... :)
-
Yeah, it's frankly amazing that anybody got 3D games running on the Genesis at all - it pushes tiles and sprites beautifully, but tile-oriented 3D rendering is at least as terrible as planar 3D rendering. I don't doubt that it's possible to run Wolf3D on a 500 (given sufficient RAM,) but it would take a smart coder who knows more than just how to re-jigger the source code into compiling for the 68K - you're not going to get acceptable performance running a renderer written for chunky bitmaps on planar hardware.
-
Doom port exists for the Spectrum too....essentially 1bit graphics though :eek:
The A8 port of Wolf is not really finished, there is no allowance for game code, and I believe it is using some weird 80x80 pixel screen mode. Looks good though, hope they have enough CPU time to make it into a game and it isn't another let down like the Shadow of the Beast rolling demo coded for the 128k Amstrad 8bit computers which can never be used for a game.
Yes, there's even a Doom port for the Spectrum, I haven't tryed it yet. The Atari port of Wolfestein is just a proof of concept (for now), but it really looks good.
That's what I love most about the 8-bit scene, people are trying to get the most out of the available hardware. There are also some very cool demo's for the zx81 (my first computer), like this one http://www.youtube.com/watch?v=gpsvgWsTX1I&feature=related.
That's something you don't see very often for a stock Amiga 500 nowadays.
-
Yes, there's even a Doom port for the Spectrum, I haven't tryed it yet. The Atari port of Wolfestein is just a proof of concept (for now), but it really looks good.
That's what I love most about the 8-bit scene, people are trying to get the most out of the available hardware. There are also some very cool demo's for the zx81 (my first computer), like this one http://www.youtube.com/watch?v=gpsvgWsTX1I&feature=related.
That's something you don't see very often for a stock Amiga 500 nowadays.
In the 8bit scenes people accept that the past has passed and just enjoy the hardware for what it is.
Unlike some of the loonies we get in the Amiga scene.
-
In the 8bit scenes people accept that the past has passed and just enjoy the hardware for what it is.
Unlike some of the loonies we get in the Amiga scene.
Excactly.
-
Excactly.
I love my 64 and Plus/4 like they are my own children. :)
I'm tempted to buy an Atari 800 one of these days though.
-
After looking at those vids, I'd reckon none of them would be worth bothering about trying to convert them to the Amiga... just more of the same old stuff that's already available for the miggie... :)
More about porting that superfast engine and tacking on Wolf3D graphics. Wouldn't be bothered about the actual game.
Just a nice two fingered salute @ 386 PC fanboys :roflmao:
-
I love my 64 and Plus/4 like they are my own children. :)
I'm tempted to buy an Atari 800 one of these days though.
The Atari 8bit is a very cool computer, it was my second computer and I always regret selling it to get a c64.
I've got one now expanded with 256K, Super Video upgrade and a SIO2SD which I put in a 1064 memory expansion case.
-
More about porting that superfast engine and tacking on Wolf3D graphics. Wouldn't be bothered about the actual game.
Just a nice two fingered salute @ 386 PC fanboys :roflmao:
Ahh... I understand now... nice idea... I like it... :)
-
In the 8bit scenes people accept that the past has passed and just enjoy the hardware for what it is.
Unlike some of the loonies we get in the Amiga scene.
That's all this is, vindication that something deemed impossible is not.Wolf needs a 16mhz ST to run modified PC source code about 12FPS. This could be genius 68k that could be adapted.
Roll on my Retirement @40 :roflmao:
-
The Atari 8bit is a very cool computer, it was my second computer and I always regret selling it to get a c64.
If got one now expanded with 256K, Super Video upgrade and a SIO2SD which I put in a 1064 memory expansion case.
Very nice! :D
When I asked my parents for an A500 as my Christmas present in 1989 they told me they couldn't afford it and I should choose something else.
I went through my Mum's shopping catalogue and saw an Atari 8-bit (Dunno which model) and thought it looked cool and asked for that or a SAM-Coupe.
I was ecstatic on xmas morning to find an A500 Batpack! :)
I've always wondered what they Atari 8-bits were like though as other than my Lynx I never owned one.
-
That's all this is, vindication that something deemed impossible is not.Wolf needs a 16mhz ST to run modified PC source code about 12FPS. This could be genius 68k that could be adapted.
Roll on my Retirement @40 :roflmao:
Oh I was referring to the loonies that think "Amiga will take over the world blah blah blah", not you. :)
-
While spectrum and atari scenes have some work and fun with their machines on the amiga world talks about kinect, games ported to some phone, some futurible intel cpu for amiga, and so on, thats the reality.
-
Sacrifices had to be made, and most importantly, bloodshot requires more mappable memory than a stock A500 can provide. Here's an interview with the programmer: http://www.segacollection.com/specials/jimbinterview.htm. It is far from Wolfenstein 3D!
-
Nah, that would be impossible, the a500 is totally underpowered.
The following videos might be shocking to some people...
http://www.youtube.com/watch?v=n_ODNdKanGc
http://www.youtube.com/watch?v=DuZywAxfGkw
;)
That's incredible. I never would have though it possible.
-
Very nice! :D
When I asked my parents for an A500 as my Christmas present in 1989 they told me they couldn't afford it and I should choose something else.
I went through my Mum's shopping catalogue and saw an Atari 8-bit (Dunno which model) and thought it looked cool and asked for that or a SAM-Coupe.
I was ecstatic on xmas morning to find an A500 Batpack! :)
I've always wondered what they Atari 8-bits were like though as other than my Lynx I never owned one.
On youtube, search for "phreakindee". He's got some cool stuff, and did a very nice review of an 8 bit atari computer (XL I believe). Very informative
-
There's also Duke3d for the megadrive. It's more of an homage than a port, but it's still pretty impressive considering the hardware.
-
There's also Duke3d for the megadrive. It's more of an homage than a port, but it's still pretty impressive considering the hardware.
And it's also approximately equivalent to Wolfenstein 3D, tech-wise. (Don't know if it uses the vertical-mirroring trick discussed in that Bloodshot interview, though.)
-
I've never seen Wolfenstein 3D run on a stock Amiga, suspect if it even exists it is not full screen (320x200 NTSC not PAL 320x256 full screen).
A wolf3d-clone would most certainly be possible on a stock (1MB) A500 in 4096 colors, just have a look at this http://www.youtube.com/watch?v=GbBGxmJVasg at around the 2:23 mark. :)
-
A wolf3d-clone would most certainly be possible on a stock (1MB) A500 in 4096 colors, just have a look at this http://www.youtube.com/watch?v=GbBGxmJVasg at around the 2:23 mark. :)
Was it running on that hardware or an OCS machine with a faster CPU?
-
"Trick or treat" (a PD game) was fully playable on A500 so it is possible.
-
Was it running on that hardware or an OCS machine with a faster CPU?
They'd be the laughing stock of the demoscene if it didn't run on a stock A500 with 1MB after claiming it does, so I would imagine it's on the hardware they claim it to be.
-
Was it running on that hardware or an OCS machine with a faster CPU?
It runs full speed on a stock 1200, and I wouldn't be surprised if it ran on a 500 as well.
The thing people are missing about demos is that they are not games; for example, Superoriginal doesn't have a working game engine with sprites, sprite occlusion, AI, free movement etc and is undoubtedly heavily optimized narrowly for exactly the kind of scene that is displayed, most likely with a lot of memory taxing precalculations. Still very impressive, but far from a game.
... and what people seem to be forgetting about other 3D games for the Amiga is that, in the end, they are not Wolfenstein 3D. There's really only one way to conclusively prove that an A500 is capable of playing Wolfenstein 3D at an acceptable framerate...
-
No idea why you guys are so amazed... Monster Maze 3D ran on an ZX81!
-
No idea why you guys are so amazed... Monster Maze 3D ran on an ZX81!
REX LIES IN WAIT...
HE IS HUNTING FOR YOU...
FOOTSTEPS APPROACHING...
REX HAS SEEN YOU...
RUN! HE IS BEHIND YOU...
A classic! One of my favorite games for the ZX81, like Mazogs, Bugburst or Hives.
-
I have two games for the genesis that are the same basic thing: Zero Tolerance, and Beyond Zero Tolerance. Both run quite well and have no extra chips in them for processing or anything. They aren't full screen but are quite playable.
here is a link:
http://en.wikipedia.org/wiki/Zero_Tolerance_(video_game)
IO have the actual cart for Zero Tolerance, just the rom for BZT. Both were released by the developer for free.
-
Very nice! :D
When I asked my parents for an A500 as my Christmas present in 1989 they told me they couldn't afford it and I should choose something else.
I went through my Mum's shopping catalogue and saw an Atari 8-bit (Dunno which model) and thought it looked cool and asked for that or a SAM-Coupe.
I was ecstatic on xmas morning to find an A500 Batpack! :)
I've always wondered what they Atari 8-bits were like though as other than my Lynx I never owned one.
I saved my paperboy money for a year to buy an Atari 600xl. It was fun to program, and great for games. The NES had it beat for games though.
-
I have two games for the genesis that are the same basic thing: Zero Tolerance, and Beyond Zero Tolerance. Both run quite well and have no extra chips in them for processing or anything. They aren't full screen but are quite playable.
here is a link:
http://en.wikipedia.org/wiki/Zero_Tolerance_(video_game)
IO have the actual cart for Zero Tolerance, just the rom for BZT. Both were released by the developer for free.
Wow!
I just cvhecked it out on youtube, it's very nice indeed!
http://www.youtube.com/watch?v=Z2OsH4ZuAlI
-
I saved my paperboy money for a year to buy an Atari 600xl. It was fun to program, and great for games. The NES had it beat for games though.
Was the 800XL the top model?
-
A wolf3d-clone would most certainly be possible on a stock (1MB) A500 in 4096 colors, just have a look at this http://www.youtube.com/watch?v=GbBGxmJVasg at around the 2:23 mark. :)
Using a copper list to produce 80x256 isn't really the same as 320x256 though. Yes, you could make a game using copper lists... but nobody would play it as it looks rubbish.
I'd rather play a blitter filled 3d game. Robocop 3 was cool for it's time.
-
Was the 800XL the top model?
I was under the impression that it was. There was a 1200XL which was physically larger, but didn't have BASIC built in(?)
edit: I got curious and checked Wikipedia, apparently the 800XL was newer than the 1200XL, and there were also the 1400XL and 1450XLD which seemed to be the "top end."
...and the 1600XL! Dual processor!
...I really hate Ataris.
-
But its almost 10% Wolfenstein 3D :)
http://hol.abime.net/5410
-
Was the 800XL the top model?
Yeah in the early 80's the 800xl was the top. The 600xl I bought off a friend ended up having a problem with the keyboard so he gave me his 800xl instead. Both were pretty good computers though, and the floppy drive was much faster than the c64 and 1541; which I got a bit later.
Mid to late 80's the xe ataris came out with more memory but really were more like the 64c being different than the c64. Not much better or worse, just a slicker case and a different number.
-
Does anyone have a working copy of Citadel in HDF format?!
-
Yeah in the early 80's the 800xl was the top. The 600xl I bought off a friend ended up having a problem with the keyboard so he gave me his 800xl instead. Both were pretty good computers though, and the floppy drive was much faster than the c64 and 1541; which I got a bit later.
Mid to late 80's the xe ataris came out with more memory but really were more like the 64c being different than the c64. Not much better or worse, just a slicker case and a different number.
I think it must have been an XE that I saw, as I thought it looked like an ST a bit.
-
Problem with A8 computers is bar the very first machines with 128 colour palette the 800/XL/XE machines only really differed in RAM fitted to them.
I have most of them but use the 800XL most, 64kb and nice keyboard to type on (not as nice as the 800 but that's 48kb so limits gaming).
Some interesting vids posted here :)
-
"Death Mask" work under Amiga 500 with 1mb and kick 1.3.
Death Mask (Amiga 500)
http://www.youtube.com/watch?v=TAXTThFUfMg
The AmigaCD32 version is the same than A500 1mb but have CDDA and joypad support,
Death Mask (Amiga CD32)
http://www.youtube.com/watch?v=KEJ68EJrn4M
-
Death Mask engine is just souped up Dungeon Master engine, look how turning left/right works ;)
-
I think Behind The Iron Gate is a pretty good FPS engine for 7Mhz Amigas. It's not fully texture mapped, but it does have some occasional textures and nice depth shading.
[YOUTUBE]Q_rFTtQ9Kuk[/YOUTUBE]
-
I think Behind The Iron Gate is a pretty good FPS engine for 7Mhz Amigas. It's not fully texture mapped, but it does have some occasional textures and nice depth shading.
[YOUTUBE]Q_rFTtQ9Kuk[/YOUTUBE]
Reminds me of Corporation, only more FPS and less RPG :)
-
Wolfenstein 3D is technically possible on a 500:a, but it's not necessarily a smooth ride. There is a port to the Atari ST (don't confuse this port with the one for the 8-bitters), and it runs rather "well" on a stock machine (like 10fps).
However, the ST has one advantage in this case - bitplanes use a 16-bit interleave. For all other purposes, this is completely retarded and hopeless to work with, but in this case it does enable the use of a faster low-resolution C2P procedure using the movep instruction. This trick can't be used on the 500:a since the smallest copper interleave possible is 32-bit (ironically the trick was evented by Amiga sceners, I've been told).
But again - ofcourse it's possible. But who would invest the time to do it?
-
Planar graphics, we has them!
From a CPU perspective, it's a go; the 68000 will most likely perform just as well as an old 286. What else do we have? Memory? I don't know anything about the memory performance of OCS Amigas, or 286 PC's for that matter. I'm sure someone else here can enlighten us, but regardless, I think both platform have enough juice.
Both the Amiga and the 286 will be able to play sounds over DMA (assuming that piece of PC junk has a soundcard), no problem there.
The only difference is the video hardware. I'm no expert, but having to do several writes to fill each pixel, when the PC only needs to do it once seems like major disadvantage for the Miggy. Thus, we need to rely on c2p conversion to get things done at a reasonable speed.
The question is: Can one of you clever coders get blazing fast c2p conversion done on a 68000? Or can you do some miraculous planar 3d engine? If not, we will have to accept that our beloved little miggies were behind even contemporary PC's, at least in some aspects.
-
Planar graphics, we has them!
Yes - and the point is that planar graphics stinks if you want to use textured walls a'la Wolf3D.
From a CPU perspective, it's a go; the 68000 will most likely perform just as well as an old 286. What else do we have? Memory? I don't know anything about the memory performance of OCS Amigas, or 286 PC's for that matter. I'm sure someone else here can enlighten us, but regardless, I think both platform have enough juice.
Both the Amiga and the 286 will be able to play sounds over DMA (assuming that piece of PC junk has a soundcard), no problem there.
The 68k is better equipped for this stuff compared to the 286. Ironically.
The only difference is the video hardware. I'm no expert, but having to do several writes to fill each pixel, when the PC only needs to do it once seems like major disadvantage for the Miggy. Thus, we need to rely on c2p conversion to get things done at a reasonable speed.
C2P is the only realistic way to achieve this, since it somewhat reduces the number of reads & writes required to address individual pixels.
The question is: Can one of you clever coders get blazing fast c2p conversion done on a 68000? Or can you do some miraculous planar 3d engine? If not, we will have to accept that our beloved little miggies were behind even contemporary PC's, at least in some aspects.
Never say never, but I'm fairly sure this is well charted territory. There is a physical limit.
-
Planar is good for certain things. Fades to grey. HAM. For a planar chip to be efficient, it would need to be triple-cored...so that each core could handle one of the three primary colors. That is the only way to get the speed out of it.
Amiga's bus is 3.57MHz. Early Amigas only move 16 bits at a time. I think the 3000 had a 32 bit bus. The reasons accelerators make just a difference in procession is the memory is 32 bit and the memory bus is faster to the cpu. It's not just the cpu that gets a bump in clockspeed, but the memory over the stock Amiga is greatly improved.
In the end, Amiga's pixel-pushing capabilities can be measured by it's memory bus.
I think the only change in the memory bus over the years was making it 32bit instead of 16bit...which moves twice as much data though at the same speed.
DRACO is considered an Amiga-compatible machine and it features a memory bus that can move 30MB/s. An A500 moves 3.57MB/s. See the difference? This is why RTG works good on Draco...a fast memory bus. Natami's bus will be capable of 3200MB/s using DDR2-400 memory, fyi. Minimig used SDRAM, fpgaarcade uses DDR1.
To get back on topic...
An A500 can probably run a World of Warcraft client. But at some point you got to ask yourself what you consider 'acceptable'. Saying you can run Wolfenstein 3D on a C64 is nice but when you think about the 1 color 32x32 resolution, you really have to ask yourself if it's worth it. 'Ports' are only worth it if the difference in the end result between platforms is 'small'.
Good ports will allow the small sacrifices to happen but also improve areas where the new platform can excell. So for instance an Atari ST game might feature gread sound and good graphics but on the Amiga it would have great graphics and good sound. See the difference? Accept the differences. Know when to draw the line.
-
Planar is good for certain things. Fades to grey. HAM. For a planar chip to be efficient, it would need to be triple-cored...so that each core could handle one of the three primary colors. That is the only way to get the speed out of it.
I have no idea how you came to this conclusion. HAM would be a lot easier to address had it been chunky/packed pixel. Fades to gray is a matter och changing the palette, not shuffling bitplanes. In 4, 8bpp or higher, I can't see any particular application which benefits from planar format, except maybe for some low fi transparency effects.
In the end, Amiga's pixel-pushing capabilities can be measured by it's memory bus.
That's true on a faster machine (i.e. 040/060) with fastmem, because the C2P conversion can be done at copyspeed anyway (i.e. you get the C2P-conversion for "free"). However, on a lower spec machine, the planar format is definitely a severe limitation.
-
The only difference is the video hardware. I'm no expert, but having to do several writes to fill each pixel, when the PC only needs to do it once seems like major disadvantage for the Miggy. Thus, we need to rely on c2p conversion to get things done at a reasonable speed.
The "PC" was not ahead in the beginning. Look at the original spec of VGA and you will find planar gfx also. The Amiga gfx were ahead of the original VGA spec. The difference was the amazing advance of PC gfx from VGA to super VGA to 3D accelerated Voodoo gfx before the Amiga could even get AGA or chunky modes that left the Amiga in the dust.
The question is: Can one of you clever coders get blazing fast c2p conversion done on a 68000? Or can you do some miraculous planar 3d engine? If not, we will have to accept that our beloved little miggies were behind even contemporary PC's, at least in some aspects.
I would rather look at a little higher spec than that. How about 68020+ with RTG gfx. This should be possible on the higher end Amiga classics as well as the upcoming fpga Amigas and UAE/AROS emulated machines in descent quality. There has already been some work to this end with Wazp3D and my optimization of an unofficial Warp3D. I can run QuakeGL in 640x400 at 20-25 fps on a 68060 classic Amiga with Voodoo 4. The overall optimization level is still quite poor. I think 800x600 would be possible at 30 fps. The Natami should be capable of significantly more. Software 3D rendering can be up to 1/2 the speed of hardware rendering if perfect rendering is not required and lower resolutions are chosen. Progress is unfortunately quite slow and what kills the Amiga.
-
I think Behind The Iron Gate is a pretty good FPS engine for 7Mhz Amigas. It's not fully texture mapped, but it does have some occasional textures and nice depth shading.
[YOUTUBE]Q_rFTtQ9Kuk[/YOUTUBE]
Wasn't this game called something else as well ? Maybe an east european title or something.
I distinctly remember playing this back in the day, but it didn't have an English title
-
But its almost 10% Wolfenstein 3D :)
http://hol.abime.net/5410
Trick Or Treat was the first 3d FPS deathmatch game I ever played :D
-
Planar graphics, we has them!
From a CPU perspective, it's a go; the 68000 will most likely perform just as well as an old 286. What else do we have? Memory? I don't know anything about the memory performance of OCS Amigas, or 286 PC's for that matter. I'm sure someone else here can enlighten us, but regardless, I think both platform have enough juice.
Both the Amiga and the 286 will be able to play sounds over DMA (assuming that piece of PC junk has a soundcard), no problem there.
The only difference is the video hardware. I'm no expert, but having to do several writes to fill each pixel, when the PC only needs to do it once seems like major disadvantage for the Miggy. Thus, we need to rely on c2p conversion to get things done at a reasonable speed.
The question is: Can one of you clever coders get blazing fast c2p conversion done on a 68000? Or can you do some miraculous planar 3d engine? If not, we will have to accept that our beloved little miggies were behind even contemporary PC's, at least in some aspects.
There is one way around writing multiple writes for a single pixel, but it isn't very good: 2 color graphics. You can use sprites to color things up, and a copper list to provide some "shading" top to bottom but thats about it.
Unfortunately C2P on a 68000 can't go fast enough. 4 color might be close but that is 4 writes per pixel, in addition to the half dozen instructions needed to calculate the pixel in the first place.
-
The "PC" was not ahead in the beginning. Look at the original spec of VGA and you will find planar gfx also. The Amiga gfx were ahead of the original VGA spec. The difference was the amazing advance of PC gfx from VGA to super VGA to 3D accelerated Voodoo gfx before the Amiga could even get AGA or chunky modes that left the Amiga in the dust....
The mode most used in Vga that is called planar is mode x, and it works a bit differently (better) than the amigas planar mode. here is a quick description of it:
http://en.wikipedia.org/wiki/Mode_X
notice two lines in that article:
Planar memory arrangement splits the pixels horizontally into groups of four. For any given byte in the PC video memory aperture, you can access four pixels on screen, by selecting the plane(s) you require.
Planar mode allows up to 4 adjoining pixels to be modified in one byte write operation, which is ideal for solid filling of objects such as polygons, rectangles, lines, etc.
Mode x was tricky to handle but could actually be faster than chunky graphics. On the Amiga Planar graphics are always slower for this type of operation. The way the Amigas graphics hardware was setup made mode x impossible or not any faster
here is a really in depth programming article on mode x:
http://www.gameprogrammer.com/3-tweak.html
-
Eh, mode X isn't planar so much as a strange hack to use the planar memory mapping hardware in chunky mode (the advantage being that it gives you access to all the video RAM, which you don't get from the BIOS-supplied linear-framebuffer chunky mode.) Actual VGA planar modes are the 16-color high-res modes and the EGA-compatibility modes.
-
Eh, mode X isn't planar so much as a strange hack to use the planar memory mapping hardware in chunky mode (the advantage being that it gives you access to all the video RAM, which you don't get from the BIOS-supplied linear-framebuffer chunky mode.) Actual VGA planar modes are the 16-color high-res modes and the EGA-compatibility modes.
The documentation I provided that showed exactly what mode x was and why it was so fast. It is a planar mode, it is much faster, and it was present in even the earliest vga systems. You could call it a hack, but it was used so extensively in games, and programming books; it was a very well known, well documented, well used hack.
The big thing I guess is that IBM provided both planar, and chunky modes in hardware and in the bios, and with a "hack" you could access 4 pixels simultaniously. The Amiga only had pure planar modes and was pretty much the opposite, instead of 4 pixels at a time, it took 4 writes per pixel, in 16 color mode.
If all Amigas had the CD32's Akikko chip they would have a similar mechanism.
here is a link for that:
http://en.wikipedia.org/wiki/Akiko_(Amiga)
-
Ooh that brings back some fond memories of the 90's for me. :)
I never tire of reading this book:
http://www.drdobbs.com/high-performance-computing/184404919;jsessionid=14VZ5MDXC5NHRQE1GHPSKH4ATMY32JVN
The mode most used in Vga that is called planar is mode x, and it works a bit differently (better) than the amigas planar mode. here is a quick description of it:
http://en.wikipedia.org/wiki/Mode_X
notice two lines in that article:
Planar memory arrangement splits the pixels horizontally into groups of four. For any given byte in the PC video memory aperture, you can access four pixels on screen, by selecting the plane(s) you require.
Planar mode allows up to 4 adjoining pixels to be modified in one byte write operation, which is ideal for solid filling of objects such as polygons, rectangles, lines, etc.
Mode x was tricky to handle but could actually be faster than chunky graphics. On the Amiga Planar graphics are always slower for this type of operation. The way the Amigas graphics hardware was setup made mode x impossible or not any faster
here is a really in depth programming article on mode x:
http://www.gameprogrammer.com/3-tweak.html
-
Ooh that brings back some fond memories of the 90's for me. :)
I never tire of reading this book:
http://www.drdobbs.com/high-performance-computing/184404919;jsessionid=14VZ5MDXC5NHRQE1GHPSKH4ATMY32JVN
Nice, I'll have to check that site out.
I have a ton of old programming books, that have lots of info on EGA, VGA and early SVGA modes including the first VESA versions.
I think it is cool that these video modes are still with us today, my newest video card is a geforce 9 series card and it can still run CGA stuff.
-
I liked Testament II game - was very playable at that time :)
http://www.youtube.com/watch?v=VpagvEPllKM&feature=related
-
There is one way around writing multiple writes for a single pixel, but it isn't very good: 2 color graphics. You can use sprites to color things up, and a copper list to provide some "shading" top to bottom but thats about it.
Unfortunately C2P on a 68000 can't go fast enough. 4 color might be close but that is 4 writes per pixel, in addition to the half dozen instructions needed to calculate the pixel in the first place.
I thought the point of fast C2P was to calculate a chunky buffer of graphics data 16 pixels wide (32 on AGA, any height as Wolf3D/Doom engines are column rendered due to the ray casting mechanism), and then do the C2P on this buffer into planer graphics memory? You still do the write per plane, but you do it for 16/32 pixels at a time rather than 1, thus saving writes.
-
Planar graphics, we has them!
From a CPU perspective, it's a go; the 68000 will most likely perform just as well as an old 286.
AFAIK EGA was also planar based.
The Catacomb Abyss (http://en.wikipedia.org/wiki/Catacomb_3-D) uses only ega and has texture mapping just like Wolfenstein 3d.
-
The documentation I provided that showed exactly what mode x was and why it was so fast. It is a planar mode, it is much faster, and it was present in even the earliest vga systems. You could call it a hack, but it was used so extensively in games, and programming books; it was a very well known, well documented, well used hack.
Well, I don't mean to imply anything negative when I call it a "hack" - it's definitely a useful mode, if a bit difficult to wrap your head around at first. I just mean that it's not a planar mode in the usual sense, where the bits of a pixel are spread across multiple linear bitmaps - each pixel is contained in one byte, it's just that the bytes for consecutive pixels are strangely interleaved by the VGA's normal planar hardware.
I never tire of reading this book:
http://www.drdobbs.com/high-performance-computing/184404919;jsessionid=14VZ5MDXC5NHRQE1GHPSKH4ATMY32JVN
Yes. Michael Abrash is a terrific writer, and his stuff is well worth the read even if you're never going to touch 80x86 programming or low-level EGA/VGA programming. His stuff did more to help me understand code optimization than anything else I'd read on the subject.
-
I have no idea how you came to this conclusion. HAM would be a lot easier to address had it been chunky/packed pixel. Fades to gray is a matter och changing the palette, not shuffling bitplanes. In 4, 8bpp or higher, I can't see any particular application which benefits from planar format, except maybe for some low fi transparency effects.
HAM is unnecessary in other formats. To change a color in a planr mode, you have to update 3 bit planes. It doesn't matter how many bits per plane you've dedicated. With chunky format you only need to update 1 plane every time. All HAM does is hold 2 planes fixed and changed the 3rd. This is why sometime you need 2 or 3 pixels to change colors horizonatally...
What can be limited on chunky displays is the pallette. HAM eliminates the limited pallette but you can only change the 1 color plane per horizonatal pixel.
In HAM is you have a black pixel(0,0,0) and you want to make the pixels next to it white, you have to change the green plane from 0 to 255, then next pixel you change red from 0 to 255, then finally in the third pixel you change blue from 0 to 255 and it finally looks white where as the first looked green and then it looked yellow.
http://en.wikipedia.org/wiki/Hold_And_Modify
So HAM opens your full pallette but limits how significant the color can change from pixel to pixel. HAM is good for real-life images but not good for precise displays such as a sharp-edged desktop.
If Amiga's display resolution got up to 1920x1080p, BUT we were limited to 4MB of video ram (6MB is required to display that resolution in 24 bit color). HAM would be useful to fill that display if the chipset was capable of doing HAM. Does that make sense?
HAM allowed you to do more colors with less memory. In video cards since today and for some time, HAM is un-necessary and irrelevant.
...
Digressing, in both chunky and planar modes, you need 6mb to display a 24bit 1080p image.
In planar mode, the memory is allocated as such:
-2MB for red plane (1 byte, 8 bits per pixel)
-2MB for green
-2MB for blue
In chunky mode, 6MB is allocated but arranged in bytes of 3:
1 byte for red, 1 byte for green, 1 byte for blue * # of pixels (1920x1080 * 3 bytes for color)
For writes, if your memory bus is 32 bits wide, you can update a pixel in 1 write operation in chunky mode. In planar mode you have to issue 3 separate writes since the color data is not sequential. You have to jump to different addresses. This is where planar mode loses. It requires 3x the bandwidth.
-
@lou_dias
You seem to be confusing something here. All HAM does is alter the way the most significant bits of a pixel are interpreted. Whether the pixels are planer or chunky is irrelevant. Nobody ever bothered creating an 8-bit chunky implementation that does it, but chunky pixels are no barrier to entry for the HAM concept. To prove it, you could easily write a software routine that converts 8-bit "HAM" pixels to 24 bit. Straight off the top of my head:
uint32 convertPixelSpan(uint32* dstARGB, const uint8* srcHAM, const uint32* paletteARGB, uint32 lastPixelARGB, size_t num)
{
/* assumes destination and palette are 32-bit ARGB words, A always 0. */
while (num--) {
/* read next HAM pixel and decode to RGB */
uint32 pixel = *srcHAM++;
switch (pixel & 0xC0) {
case 0x40: /* change upper 6-bits red */
lastPixelARGB = ((lastPixelARGB & 0x0003FFFF) | (pixel & 0x3F) << 18);
break;
case 0x80: /* change upper 6-bits green */
lastPixelARGB = ((lastPixelARGB & 0x00FF03FF) | (pixel & 0x3F) << 10);
break;
case 0xC0: /* change upper 6-bits blue */
lastPixelARGB = ((lastPixelARGB & 0x00FFFF03) | (pixel & 0x3F) << 2);
break;
default: /* use palette value */
lastPixelARGB = paletteARGB[pixel];
break;
}
*dstARGB++ = lastPixelARGB;
}
/* return the last calculated pixel for future calls */
return lastPixelARGB;
}
Such an implementation would be trivial in hardware, I would suggest actually using planar graphics makes it more difficult rather than less (except in the case of HAM6 where there's no convenient chunky representation).
-
I thought the point of fast C2P was to calculate a chunky buffer of graphics data 16 pixels wide (32 on AGA, any height as Wolf3D/Doom engines are column rendered due to the ray casting mechanism), and then do the C2P on this buffer into planer graphics memory? You still do the write per plane, but you do it for 16/32 pixels at a time rather than 1, thus saving writes.
c2p or chunky to planar is any algorythm that takes a chuncky frame buffer and writes to a planar graphics arrangement. There are lots of ways to do it, and none are as fast as simply writing a chunky buffer. Because one chunky pixel has to be broken into bits and stored in each plane of the output.
In other words there is no hardware "magic" like with mode x on vga that makes it faster.
If you use 2 color (wireframe or pattern) graphics there is only one plane so it is as fast as chunky.
-
Well, I don't mean to imply anything negative when I call it a "hack" - it's definitely a useful mode, if a bit difficult to wrap your head around at first. I just mean that it's not a planar mode in the usual sense, where the bits of a pixel are spread across multiple linear bitmaps - each pixel is contained in one byte, it's just that the bytes for consecutive pixels are strangely interleaved by the VGA's normal planar hardware.
Yes. Michael Abrash is a terrific writer, and his stuff is well worth the read even if you're never going to touch 80x86 programming or low-level EGA/VGA programming. His stuff did more to help me understand code optimization than anything else I'd read on the subject.
I didn't think anything bad when you said "hack" I just meant that it is such a feature that it works perfectly on every single IBM and compatible clone cards. IBM had bios modes that were a subset of what the vga chip could actually do, and the clone cards included it.
mode x also had "square" pixels so no scaling was neccisary before displaying graphics.
Its kind of like ham in a way, its not a normal method of graphics output but it has some excellent uses. Ham displayes more colors, Mode x is very fast. Ham may have been more designed into the hardware though.
-
c2p or chunky to planar is any algorythm that takes a chuncky frame buffer and writes to a planar graphics arrangement. There are lots of ways to do it, and none are as fast as simply writing a chunky buffer. Because one chunky pixel has to be broken into bits and stored in each plane of the output
Whilst this observation is true in theory, in practise you can hit other bottlenecks first. On the amiga, the speed at which you can write to Chip RAM soon becomes a limiting factor (not for vanilla 68000, but certainly for 68040/68060) such that the time it takes to perform the C2P is masked by the time it takes to simply shovel the data from Fast RAM to Chip RAM. Once you hit that wall, your routine is indistinguishable in performance terms from simply copying, the data.
-
Planar is good for certain things. Fades to grey. HAM. For a planar chip to be efficient, it would need to be triple-cored...so that each core could handle one of the three primary colors. That is the only way to get the speed out of it.
?????
BTW, does someone have an example of HAM c2p? Sounds kind of processor intense but it would be cool :)
-
?????
BTW, does someone have an example of HAM c2p? Sounds kind of processor intense but it would be cool :)
There are various 18-bit C2P routines on Aminet, IIRC.
-
@lou_dias
You seem to be confusing something here. All HAM does is alter the way the most significant bits of a pixel are interpreted. Whether the pixels are planer or chunky is irrelevant. Nobody ever bothered creating an 8-bit chunky implementation that does it, but chunky pixels are no barrier to entry for the HAM concept. To prove it, you could easily write a software routine that converts 8-bit "HAM" pixels to 24 bit. Straight off the top of my head:
uint32 convertPixelSpan(uint32* dstARGB, const uint8* srcHAM, const uint32* paletteARGB, uint32 lastPixelARGB, size_t num)
{
/* assumes destination and palette are 32-bit ARGB words, A always 0. */
while (num--) {
/* read next HAM pixel and decode to RGB */
uint32 pixel = *srcHAM++;
switch (pixel & 0xC0) {
case 0x40: /* change upper 6-bits red */
lastPixelARGB = ((lastPixelARGB & 0x0003FFFF) | (pixel & 0x3F) << 18);
break;
case 0x80: /* change upper 6-bits green */
lastPixelARGB = ((lastPixelARGB & 0x00FF03FF) | (pixel & 0x3F) << 10);
break;
case 0xC0: /* change upper 6-bits blue */
lastPixelARGB = ((lastPixelARGB & 0x00FFFF03) | (pixel & 0x3F) << 2);
break;
default: /* use palette value */
lastPixelARGB = paletteARGB[pixel];
break;
}
*dstARGB++ = lastPixelARGB;
}
/* return the last calculated pixel for future calls */
return lastPixelARGB;
}
Such an implementation would be trivial in hardware, I would suggest actually using planar graphics makes it more difficult rather than less (except in the case of HAM6 where there's no convenient chunky representation).
Not sure what you were replying to but what is the point of converting HAM to chunky? Unless ofcourse you're trying to port graphics to another platform...and they were natively saved as HAM images...
HAM is used as a lossy image conversion/display when you need to display more colors with limited RAM. The trade off for saving memory is you can only 'modify' 1 plane at a time.
It's 24bit Chunky that gets converted down to HAM for displaying purposes. No one goes back the other way...
-
@lou_dias: No, you completely missed the point of my argument. It was about the most efficient way of addressing single pixels in a framebuffer. If that's HAM, a truecolor mode, or a CLUT-based mode is of no importance.
Changing a single pixel in a planar mode requires a shitload of instructions, whereas changing a chunky pixel requires 1 instruction. The required bandwidth to do so is a different discussion, but if we do take it into the equation, planar format makes the bandwidth issue even worse when addressing single pixels, since changing a single pixel means both reading and writing data to screen memory and requires several accesses to finish.
The workaround for this is to use an accelerated machine, and have a chunky buffer in fastmem. All accesses are performed against the chunky buffer, which then has to be converted and copied to chipmen. This method can't be used efficiently on a stock machine, but a stock machine would instead benefit a lot from having chunky pixel format instead of planar.
-
AFAIK EGA was also planar based.
The Catacomb Abyss (http://en.wikipedia.org/wiki/Catacomb_3-D) uses only ega and has texture mapping just like Wolfenstein 3d.
Yeah, I thought about that a few days ago. Too bad it's not open-source like Wolfenstein is.
-
@Changing a single pixel in a planar mode requires a shitload of instructions, whereas changing a chunky pixel requires 1 instruction.
Damn right - but changing 16 aligned consecutive pixels in planar mode requires the same amount of instructions. C2P from 16 chunky pixels in fast ram to chip RAM does save a lot of bandwidth over the worst case scenario.
It's just that pretty much any programmer would implement this - however C2P involves a lot of ORing and shifting - precisely what Akiko does for free on the CD32. I'm sure someone has done something fast with pre-calculated lookup tables but on a 7MHz 68000 it's still very heavy.
But doable in a smaller window, 2x1 pixels, lower framerate (not for action FPSes, but fine for RPGs), etc. If a 4MHz Z80 can render a semblance of Wolf3D graphics (http://www.youtube.com/watch?v=COH55Uj53TY) then an A500 can as well.
-
But doable in a smaller window, 2x1 pixels, lower framerate (not for action FPSes, but fine for RPGs), etc. If a 4MHz Z80 can render a semblance of Wolf3D graphics (http://www.youtube.com/watch?v=COH55Uj53TY) then an A500 can as well.
I definitely agree with you, but I just have to point out that your video example is not entirely real time - it's still far from from an interactive engine in that distances and texture coordinates are precalculated, as is explained in the video description. I'm sure you know this, but just before anyone else goes into a frenzy :)
-
I definitely agree with you, but I just have to point out that your video example is not entirely real time - it's still far from from an interactive engine in that distances and texture coordinates are precalculated, as is explained in the video description. I'm sure you know this, but just before anyone else goes into a frenzy :)
True, but we are talking about the rendering aspect at the moment, rather than the calculation aspect. :-) I expect the calculation will kill the Z80 version, and be tough on a 68000 even with lookup tables.
-
Damn right - but changing 16 aligned consecutive pixels in planar mode requires the same amount of instructions. C2P from 16 chunky pixels in fast ram to chip RAM does save a lot of bandwidth over the worst case scenario.
Changing 16 aligned consecutive pixels in planar mode is fairly useless in a texturemapper in a typical Wolf3D scenario :) And I'm not sure it's true either - in chunky mode you'd do that with a single movem, but in planar mode you'll have to take into account that the bitplanes have a 32-bit interleave (copper interleave).
It's just that pretty much any programmer would implement this - however C2P involves a lot of ORing and shifting - precisely what Akiko does for free on the CD32. I'm sure someone has done something fast with pre-calculated lookup tables but on a 7MHz 68000 it's still very heavy.
It doesn't do it for free. You have to write 32 pixels and read them back, then copy them to the screen. I agree it's better, but it still stinks compared to having a real chunky mode.
But doable in a smaller window, 2x1 pixels, lower framerate (not for action FPSes, but fine for RPGs), etc.
Indeed! Wasn't Legends of Valour released for the Amiga?
If a 4MHz Z80 can render a semblance of Wolf3D graphics (http://www.youtube.com/watch?v=COH55Uj53TY) then an A500 can as well.
I'm not sure it's a good comparison. The problem is not CPU speed, the problem is that the pixel format of the framebuffer isn't suited for that kind of stuff. The CPU has more than enough juice to do it.
-
What's "copper interleave" - the only references I can find on Google are this thread, and another post by you regarding Atari ST emulation on the Amiga?
It can't be relating to ILBM, as that's a file format that merely stores planar graphics on a row-by-row basis.
-
Not sure what you were replying to but what is the point of converting HAM to chunky? Unless ofcourse you're trying to port graphics to another platform...and they were natively saved as HAM images...
HAM is used as a lossy image conversion/display when you need to display more colors with limited RAM. The trade off for saving memory is you can only 'modify' 1 plane at a time.
It's 24bit Chunky that gets converted down to HAM for displaying purposes. No one goes back the other way...
You seemed to be implying that planar pixels were somehow advantageous for implementing HAM. They're not; the HAM concept can work just as well if the pixels were planar or chunky. The code was just to demonstrate how a chunky 8-bit HAM mode might work (though in any real system you'd implement it in HW).
In fact, it might even be the case that it would take less logic to implement a chunky HAM system than a planar one.
-
In fact, it might even be the case that it would take less logic to implement a chunky HAM system than a planar one.
Given that HAM is by necessity fixed at a certain bit-depth, there's certainly no advantage to its being planar (besides the relevant one for OCS, that it allows reuse of the existing planar hardware.)
-
The amount of epeen in this thread is growing rapidly.
/me sits back, grabs popcorn, and waits for someone to bring joyport polling into the equation.
-
You seemed to be implying that planar pixels were somehow advantageous for implementing HAM. They're not; the HAM concept can work just as well if the pixels were planar or chunky. The code was just to demonstrate how a chunky 8-bit HAM mode might work (though in any real system you'd implement it in HW).
In fact, it might even be the case that it would take less logic to implement a chunky HAM system than a planar one.
Ah.
Well my point is if you have a 24bit chunky mode HAM is irrelevant. HAM was only an advantage in the old days of limited RAM and inability to display lots of colors on the screen at once. It's a lossy format...just like most people feel about 80% jpeg compressed images and 128kbps MP3's...
HAM is one piece of tech that can go the way of the dodo bird since about 1994.
-
given isa bus limitations and ocs superiority joystick polling is integral to the discussion. If you send 15 megs over the bus in vga snoopdog mode and 10msec later poll the joystick port, you get flashed by the planar chick. Amiga has Paula (i dated a girl named paula once, nice girl, nicccely chunky:) ) and you can poll the port every nth nanosecond.
with or without popcorn!
-
You do have to ask, Would Gary Busey poll the josystick port at such frequency tho? Stellan Skarsgård might but would Gary Busey?
-
What's "copper interleave" - the only references I can find on Google are this thread, and another post by you regarding Atari ST emulation on the Amiga
Ah. Clarification. On the Amiga, bitplanes are ordered consecutively (i.e. it's like multiple monochrome bitmaps layered on top of each other).
On the ST, they're interleaved (1 word from plane 0, followed by 1 word from plane 1, by one word from plane 2, one word from plane 3, one word form plane 0 ... etc).
Using the copper, it's possible to create something similar: 1 longword for plane 0, 1 longword for plane 1, 1 longword for plane 2, 1 longword for plane 3 etc. I suspect that it's fairly useless to do so however, and hence it's possible that the term "copper interleave" isn't very common at all.
Note: Word in this case is 16 bits, longword is 32 bits.
-
given isa bus limitations and ocs superiority joystick polling is integral to the discussion. If you send 15 megs over the bus in vga snoopdog mode and 10msec later poll the joystick port, you get flashed by the planar chick. Amiga has Paula (i dated a girl named paula once, nice girl, nicccely chunky:) ) and you can poll the port every nth nanosecond.
with or without popcorn!
lol :) It's just a matter of time now.