Port Wolfenstein on Amiga 500 / 1000 OCS

[LongLifeA1200]

Originally Posted by Miggy4eva

I'm just kickstarting a conversation and gathering information to one place

If it'll help others learn how to achieve 2.5D on lower-end systems, that in itself would be interesting.

Originally Posted by Miggy4eva

The 5mhz version is actually running on an 8-bit 8088! At 4.77mhz!

They call it a slideshow, though. The game is over before the player knows what happened.

Each 1mhz is a million cycles per second.

The stock A-500/600/1000/2000 is;
+ (1,000,000 + 1,000,000) cycles per second faster,
but,
- (1,000,000 + 1,000,000 + 1,000,000) cycles per second slower than the 10mhz PC which probably achieves ~15 frames per second at full screen size which is the bare minimum for someone to consider Wolf3D "playable".

Now I don't know if the Motorola 68k can do more instructions per second than Intel's 286 or 8088 at the same mhz speed, but apparently:

10mhz 750,000 instructions per second Intel 8088
8mhz 1,400,000 instructions per second Motorola 68000

12mhz 1,280,000 instructions per second Intel 286
12.5mhz 2,188,000 instructions per second Motorla 68000

I don't know if those figures are accurate (I don't even know where they came from). I'd take it with a grain of salt.

Originally Posted by britelite

You're already setting your expectations WAY too high, so you would only be disappointed by the end result. Trust me when I say that the ST-version is pretty much exactly what you would get on an A500.

Originally Posted by Miggy4eva

Really?? Only as slow as that garbage version? I really hope not.

Atari ST also uses the Motorola 68000 processor at similar if not equal speed.

Originally Posted by Miggy4eva

I feel like this is the version we must beat, not copy. In the old days the Amiga got so many ST Lazyports and to get one today is just humiliating. I must admit this ST version annoys me very much sometimes with Atari people trying to start fights about it.

I hope this isn't just to prove a point to Atari ST fans.

Originally Posted by Miggy4eva

I know it's possible because of so many other "tips of the iceberg" we have seen in other Amiga demo's and games.

I'd say in those cases they were pushing the system to the maximum, not conserving it.

Originally Posted by Samurai_Crow

Porting the Mac version would be better than the DOS version because the QuickDraw plotter used non-textured polygons instead of texture mapping. The Amiga polygon plotter is still not fast enough but it would still avoid the chunky to planar conversion.

Originally Posted by Miggy4eva

OK that sounds great, avoiding C2P would clear the main obstacle!!

So the Apple QuickDraw library can draw polygons more efficiently than the Amiga Graphics library on the same Motorola 68000 and mhz? Worth more investigation.

Originally Posted by britelite

Come on, name ONE thing where a Wolf3D-game would graphically benefit from the A500 hardware? There's no point in discussing these thing unless you have concrete suggestions to put on the table.

Originally Posted by Miggy4eva

Compared to Atari version - copper and blitter. Copper to assist c2p and change palettes for more colours on screen, and perform mode 7 "like" (I know mode 7 is SNES) operations to appear like texture mapping and cheat in some areas and save CPU. Blitter to help shift data around the screen, scale the sprites, and one idea I have is in first-person when the player stands still and turns around with the side cursor keys instead of doing 3d the blitter can just scroll the image in silky-smooth 50fps. With some smart code we could detect whenever the player is just turning or when some object is only moving sideways, and scroll it directly in planar instead of rendering in 3d in chunky and then converting.

In 3D, angles are drawn to the "vanishing point". Only flat surfaces with a horizontal axis that is parallel to the player's strafing axis line would remain unchanged during scrolling until the player moved away or toward them at which point they need to be re-scaled.

As for Mode 7 "like", I'm not sure what you mean. SNES was released in 1990 and I don't recall any Amiga game being able to rotate and scale a single large image quite so fast as the SNES could.

It's kinda depressing to keep comparing Commodore-Amiga to systems that were released years later. It might have been ahead of its time, but it wasn't future-proof.

Originally Posted by Miggy4eva

I think it would be AWESOME for someone to make Stuntcar racer faster on Amiga! It always suffered from lazyport syndrome.

Not everything can be explained as a "lazy port". If anything can make a game on Amiga run faster, it's an accelerator card.

Originally Posted by Samurai_Crow

Stunt Car Racer is a good example of what an Amiga 3D game should be. It uses the Blitter to plot polygons instead of chunky to planar routines.

That's interesting.

Originally Posted by Megol

BSP is probably better than raycasting.

Would be worth running a test to see if Binary Space Partitioning is less demanding on the CPU than Raycasting for a simple 2.5D game.

Originally Posted by Miggy4eva

I have attached the resources for Wolfenstein including all sprites and textures.

Never convert PNG to JPG - it ruins the quality. You'll have to resource that sprite sheet. You'll also need all the midi and sound files. To have any sort of "Victory" though, you'll need to find someone who'd be willing to recompose the music into mod files and I don't mean just anybody - because frankly, all the Wolf3D music remixes I've heard (so far) sound worse than the original midi version because they're trying WAY too hard.

Originally Posted by Miggy4eva

I'm far too old to learn a new trick like programming.

That can't be true.

[AJCopland]

Originally Posted by Miggy4eva

I'm sorry but I'm far too old to learn a new trick like programming. Besides, I have other skillsets in my life which programmers do not have, maybe one of them is to help motivate and organise to get this project done.

A) My great uncle learnt to program when he was 84 years old.
B) Most games programmers are polymaths, we can do a bit of everything because we _have_ to

Is this the Wolf3D Mac source code people were talking about using a as a base? https://github.com/Blzut3/Wolf3D-Mac

[StingRay]

Originally Posted by Samurai_Crow

Stunt Car Racer is a good example of what an Amiga 3D game should be. It uses the Blitter to plot polygons instead of chunky to planar routines.

Why should a game such as Stunt Car Racer use chunky to planar? Doesn't make sense at all and almost all of the A500 3d games use the same technique, i.e. blitter to draw and fill polygons.

[Daedalus]

That's the point he was making - it's using the Amiga's capabilities, rather than with texture mapping where you're replacing missing capabilities with CPU-bound software rendering routines, and thus slowing to a crawl.

[StingRay]

That implies fast texture mapping is not possible on A500 which is not true either!

[Daedalus]

Indeed, but it's a hell of a lot slower than flat polygons, and given the lack of chunky graphics modes, is a much bigger ask of the machine than it would otherwise be.

[nobody]

Instructions in theory

8088@4.77 357.000
68000@7.14 1.249.000
68020@14.28 4.326.000
286@12 1.284.000
386@16 2.150.000

[Megol]

Originally Posted by nobody

Instructions in theory

8088@4.77 357.000
68000@7.14 1.249.000
68020@14.28 4.326.000
286@12 1.284.000
386@16 2.150.000

Doesn't say much without specifying what kind of instructions etc. The 8088 have a 8 bit memory bus which makes a difference even with the same theoretical instruction throughput and the 68k can do 32 bit operations with a small overhead while the 8088 have to do it with two instructions.

IOW it's hard to directly compare without having two routines doing the same thing.

[Amiga1992]

Originally Posted by LongLifeA1200

Never convert PNG to JPG - it ruins the quality. You'll have to resource that sprite sheet.

Originally Posted by Miggy4eva

I understand more than you think and I'm a very technical person.

I had not even looked at that thing.

[Leffmann]

Don't be such a loser and asshole Akira. Convert the graphics yourself if you're so damn good?

OP specifically asked for a civilized discussion from people who were interested in the topic, and since you joined you've done nothing but show your usual bully attitude and try to shoot down OP's ideas and motivations.

[britelite]

Originally Posted by Leffmann

Convert the graphics yourself if you're so damn good?

You do realize the OP didn't even convert the graphics, but rather posted the originals in a unusable lossy format?

[Amiga1992]

Originally Posted by Leffmann

Don't be such a loser and asshole Akira. Convert the graphics yourself if you're so damn good?

OP specifically asked for a civilized discussion from people who were interested in the topic, and since you joined you've done nothing but show your usual bully attitude and try to shoot down OP's ideas and motivations.

Leffmann, EAB's vigilante defender of fools, has struck against me again. I will not be able to sleep tonight.

The OP has clearly been criticized for not having a single idea and to motivate nothing in anyone, and not just by me. As usual you take the side of anyone I criticize or joke with just to antagonize me, because I see you only mentioning me, not anyone else, just because I made a joke.
It's your favorite hobby. I wish you had a real hobby.

[nobody]

Everything about that game is here

https://www.spriters-resource.com/pc...wolfenstein3d/

[Leffmann]

Originally Posted by britelite

You do realize the OP didn't even convert the graphics, but rather posted the originals in a unusable lossy format?

It's not about the graphics, it's about how people join not to contribute or discuss, but to bully and shoot the thread down. It makes people wary of starting new discussions and sharing ideas, and only serves to quiet down the forum.

[britelite]

Originally Posted by Leffmann

It's not about the graphics, it's about how people join not to contribute or discuss, but to bully and shoot the thread down.

Well, sure, but when the OP doesn't really understand his own topic and is incapable of accepting facts from people with actual knowledge, then it doesn't lead to a very fruitful discussion, now does it?

It makes people wary of starting new discussions and sharing ideas, and only serves to quiet down the forum.

Do you rather want threads with raving lunatics ranting on about things they don't understand, or some sensible discussion that could actually lead somewhere?

EDIT: I mean, in the thread the OP hasn't given any concrete ideas on how to move forward, but rather given demands and "wish lists" that have no basis in reality, and won't acknowledge facts when told. And this will only serve the opposite of what OP is hoping for, that is, discourage people with the required skills from actually helping the OP.

[britelite]

Bottom line: if you want to see Wolf 3D on the A500:

DO actually present something you've done yourself and ask for help, or have some other REAL suggestions for cool optimizing tricks that someone might want to try out.

DON'T rant on about how awesome the A500 is and how it should be capable of fullscreen 1x1 wolf3d in full framerate with thousands for colors, if you have no way of backing up your claims. You will only be disappointed as that's something that no-one will be able to achieve.

[LongLifeA1200]

Here's some notes from the person that ported Wolf3D to 8088:

"it was surprisingly easy, actually. it only involved removing the bit that quits if it doesn't detect a 286, and going through each source file looking for assembly instructions that aren't 8086-compatible, and replacing them."

"i removed the code that makes the game quit if it doesn't detect at least a 286. i also had to modify a good portion of the assembly where it used SHL/SHR ops with more than 1 place bit shifting. there was quite a bit of that, i just changed it to multiple single shifts so that an 8088 could run it."

"the SHL and SHR operations move the bits in a value left or right (respectively). if you move all the bits in a value one place to the left, it doubles the number. if you move them all one to the right, it halves the number. with the introduction of the 286 (or maybe it was the 186, i forget) those SHL/SHR operations became able to accept an argument telling it how many places to move the bits at once rather than having to use multiple ops. for example an SHL with the argument of 3 has the same end result as three single SHLs on an 8088, but it's done 3 times faster."

"the 8088 is actually a true 16-bit processor, just like the 8086. the difference between them is that the 8088 only has an 8-bit wide interface to external data, like from RAM."

"i actually got another 8088 motherboard recently which actually runs the CPU at 10 MHz on turbo mode. i tried wolf3d on that for a few minutes, it was quite playable. you still have to have the view shrunk, but it's still fun to play."

Getting back to the Mac port however...

Originally Posted by alexh

Surely starting with the Apple IIgs source (which is what they did for the AtariST demo) is the way to go.

The source is already configured for a 16-bit host CPU with no FPU but it does have chunky graphics.

Originally Posted by Miggy4eva

I am just very worried about a lazyport that doesn't use Amiga's full abilities with that approach.

Originally Posted by AJCopland

Is this the Wolf3D Mac source code people were talking about using a as a base? https://github.com/Blzut3/Wolf3D-Mac

The Mac port has some interesting notes worth reading:

The code was based not on the PC version but of a Super NES version that was done at id software. This version of the game differs greatly from the PC version since it used BSP trees to help determine which walls were to be drawn instead of the ray-casting method.

The fixed point number system was 8.8 format so that it could fit in a 65816 register for the SNES and Apple IIgs version of Wolf 3D. (8 bits of integer and 8 bits of fraction)

The mac version also has two modes of drawing. In the 68000 version, 68000 code is generated at runtime to draw the vertical lines very quickly. The source file SetupScalers68k.c creates the 68000 code and then issues calls to it via a little 68000 assembly glue code. This is how the game got its speed. The powerpc version originally had this method as well but the performance sucked. So it was changed to a simple assembly loop and the game ran fine. This is why there is SetupScalersPPC.c and SetupScalers68k.c.

But the thing to keep in mind is:

Wolfenstein 3D for MacOS was released on October 1st, 1994

Question is, how many tri-polygons can the stock A500 do per second (or nano-second)?

Does the blitter care how many or how complicated polygons are?

Would superimposing unfilled polygons onto doors and walls for detail still be faster than texture mapping on the A500?

[britelite]

Originally Posted by LongLifeA1200

In the 68000 version, 68000 code is generated at runtime to draw the vertical lines very quickly. The source file SetupScalers68k.c creates the 68000 code and then issues calls to it via a little 68000 assembly glue code.

This is pretty much the way it should be done on A500 too (and how I've done it).

Question is, how many tri-polygons can the stock A500 do per second (or nano-second)?

Texture mapped or flat?

Does the blitter care how many or how complicated polygons are?

Not while doing a blitter fill, but the time used for setting up the polygons and drawing the edges (either by blitter or cpu) will of course depend greatly on the size and amount of polygons.

Would superimposing unfilled polygons onto doors and walls for detail still be faster than texture mapping on the A500?

I would say no, at least if you want the level of detail that texture mapping would give.

[LongLifeA1200]

Originally Posted by britelite

Texture mapped or flat?

Flat-shaded and unfilled (wireframe) for both PAL and NTSC. Something that fills the screen so that anything missing in the bottom right corner makes it easy to tell if the A500 can't reach a certain number before the next frame. Rows of "right angle" triangles forming squares that fill up the screen, with an equal amount in each row.

Originally Posted by LongLifeA1200

(or nano-second)

Erm, disregard that - that is far too percise.

1 second = 1,000 milliseconds.

50FPS PAL 1 frame every 20 milliseconds (1/50th of a second).
60FPS NTSC 1 frame every 16.6-recuring milliseconds (1/60th of a second).

30FPS Acceptable 1 frame every 33.3-recuring milliseconds (1/30th of a second).
15FPS Playable 1 frame every 66.6-recuring milliseconds (1/15th of a second).

Polygon Budget:

If we know how many polygons can be drawn per frame (or in milliseconds), and know how much time is left remaining after the minimum amount of game logic is computed, then we'll have our polygon budget.

Let's say to maintain a respectable 30 frames per second, in each frame the A500 has only 33.3 milliseconds to compute the game and draw to screen. After the game logic is computed for that frame, whatever time is left over during that 33.3 milliseconds will be how many polygons the A500 might be able to draw/render.

All that matters right now is what the Motorola 68000 needs to do at a minimum every frame. If it needs at least 70 milliseconds before the next frame, the battle is already lost.

[britelite]

Originally Posted by LongLifeA1200

If we know how many polygons can be drawn per frame (or in milliseconds), and know how much time is left remaining after the minimum amount of game logic is computed, then we'll have our polygon budget.

Have a look at polygon based 3D-games on the A500, that's the approximate framerates and level of detail you'll get. A wolf3d style game with only flat walls is doable if you go with the polygon route. If you want to add a level of detail that is even remotely close to what you'll get with texture mapping, it'll crawl down to a halt.