Port Wolfenstein on Amiga 500 / 1000 OCS

[britelite]

Originally Posted by Gorf

how about using a repeating pattern for these mentioned "stripes"?
something around 10 - 20 pixel starting all over again and again until the stripe has reached its full hight.
For shorter stripes we use scaled-down versions of the same pattern.

And what would you do with these stripes? As you described it, it would just look like a mess.

If this was a (non-rotating) floor/ceiling, then this would make more sense as you could switch palettes every scanline to draw the texture. But this doesn't work on vertical walls.

to put things in the right space with copper and blitter, something like this could be used:

CharMode

Well, this would give us a crude chunkymode with very low resolution, and I don't really see how this relates to the "stripes" you talked about.

[Gorf]

Originally Posted by britelite

And what would you do with these stripes? As you described it, it would just look like a mess.

the same as they did in the video.
the walls are broken down into stripes. these stripes are scaled for the "mapping".

Since scaling is to expensive and keeping all possible stripes in memory needs way too much ram, the idea is to break down these stripes even further in repeating sub-stripes instead.

your walls may now look a little bit awkward, but with the right patterns a nice look should be possible.

Well, this would give us a crude chunkymode with very low resolution,

basically yes, but since these blocks/sub-stripes are not uni-colored but consist of patterns it gives the impression of a higher resolution.

and I don't really see how this relates to the "stripes" you talked about.

hope my explanation above clarifies that.

[Megol]

Character based rendering can produce something usable (but not nice looking), the ZX Spectrum have some wall rendering demos that shows that the basic idea work:
"Doom"
[ Show youtube player ]
Wolf 3D
[ Show youtube player ]

Don't think that approach would be good for the Amiga, at best one would render to a charset thingy with the limitations of that and then having to convert it to planar.
Would be better to do some type of chunky rendering + c2p then - at least it would look nicer.

[britelite]

Originally Posted by Gorf

Since scaling is to expensive and keeping all possible stripes in memory needs way too much ram, the idea is to break down these stripes even further in repeating sub-stripes instead.

Ahh, yes. Not really a working solution for a wolf3d-port, but you could of course design your own game around this method. And this would still eat a great amount of precious chipmem.

[Retro1234]

Originally Posted by saimon69

@eXeler0

Actually i would consider this video more on-topic (and btw the coder is coming from the demoscene )

[ Show youtube player ]

This is good Not the mirroring but expalin how the effect is done with vertical lines.

How many different graphics for the walls are we talking for level 1?.We're talking about 110 arrays of 16*16? for the walls - you can blit 320 16*16 tiles to fill a screen quick so should be able to blit 320*256 1*1 pixles quick enough?


Yes I thinks it's possible but would need someone with a seriously good Maths Brain

[Gorf]

Originally Posted by britelite

Ahh, yes. Not really a working solution for a wolf3d-port, but you could of course design your own game around this method. And this would still eat a great amount of precious chipmem.

Well ... it is certainly no wolf ... more like a dog or a puppy

"Puppypebble2.5D"


It would probably be closer to this C64-version than to the PC-version:

[ Show youtube player ]

[LongLifeA1200]

Thanks for recommending GameHut. Those Jon Burton videos are great.

Using Jon Burton's math, however, displaying only 8 pixel wide walls at right angles to the player's point of view to avoid any extra processing and in 16 colour (for Amiga OCS systems):

Full Screen
PAL resolution: 320x256 variable frame rate: 8 - 14 per second.
NTSC resolution: 320x200 variable frame rate: 11 - 18 per second.

Half Height
PAL resolution: 320x128 variable frame rate: 17 - 28 per second.
NTSC resolution: 320x100 variable frame rate: 22 - 36 per second.

Half Screen
PAL resolution: 160x128 variable frame rate: 34 - 57 per second.
NTSC resolution: 160x100 variable frame rate: 44 - 74 per second.

The low number is walls filling the screen from top to bottom.
The high number is walls so far away that they are only 1 pixel tall.

And all this if the game is doing absolutely nothing. This method of drawing to the screen doesn't leave the CPU with much time to do anything else at those resolutions.

[LaBodilsen]

After following this discussion, and others on the same topic (2.5D raycasting on Amiga500), i think i would like to join in. both with ideas, and also with work like eg. converting graphics and coding. (i do have recent experience with coding on Amiga, and did release demo and intros some 25 years ago)

- The Idea -
I have been thinking about using the blitter to draw the wall strips, By basicly using the same technique as the old 102 scroll register trick, but doing it verticaly with the blitter, instead of the copper.

Then have the texture in memory pre-scaled at 16px intervals (eg. 64px, 48px, 32px 16px). and use the blitter to pick out the correct parts and blit them vertically below each other. So for a 64pix high wall strip, we could blit 4 * 16px high blocks of 2px wide from the 64px texture. and for a 52px high wall we would blit 4 * 13px high blocks from the 64px texture, and by that scale the 64px texture to 52px.

code for each wall height could be pre-made just like a normal wall strip drawing rutine.

So like in the video about toystory, use a Raycast resolution of 160 pixels wide, and blit texture strips of 2 pixels wide, but with 2 uniqe pixels for each strip. given the same level of detail as the Toystory video.

I havent done any testing yet. but the coding would look a lot like a 102 register zoomer, which i have never done myself, so i would like some thoughts from the coders in here. also thoughts on how to do "bigger than texture size" wall strips with this technique, would be kinda tricky.

[britelite]

Originally Posted by LaBodilsen

I havent done any testing yet. but the coding would look a lot like a 102 register zoomer, which i have never done myself, so i would like some thoughts from the coders in here.

In the context of Wolf3D I have a feeling that the prescaled texture would fill up memory very quickly. But definitely something worth trying out, if nothing else it could make for a nice demo part

[LaBodilsen]

@Britelite

True.. Wolf3D have around 51 unique wall textures, not counting the halftones. so for all these to be prescaled in 16col 4bit textures, would take up 256kb of memory.

That is not counting, enemy's and objects.

so yes, if this technique is to be used, we would need to either reduce the number of textures, and/or introduce some form of smart loading, to only load the textures needed for a level.

[LongLifeA1200]

Partition each room seperated by a door into individual maps. The animation and sound fx of the door opening and closing against a blank screen, can serve as the mini-loading/transition screen.

[turrican3]

Originally Posted by hooverphonique

The point here is that the Genesis has 2 chunky pixels per byte, which is what really makes the difference compared to the amiga - all the other speed-ups mentioned are trivial.

I see, the cd32 akiko could make the job ??? or not ???
because, why not a cd32 version ??
Akiko is a kind of c2p hardware, no ???
What's the speed of conversion of akiko vs 680x0 pcu ??? a 030 25mhz ? Perhaps less ?

[Samurai_Crow]

Originally Posted by turrican3

I see, the cd32 akiko could make the job ??? or not ???
because, why not a cd32 version ??
Akiko is a kind of c2p hardware, no ???
What's the speed of conversion of akiko vs 680x0 pcu ??? a 030 25mhz ? Perhaps less ?

Because it is off-topic for this thread. This thread is about doing it on OCS A500/A1000.

[LaBodilsen]

Also the CD32 already have a version:

http://eab.abime.net/showthread.php?t=74074

[Megol]

Originally Posted by LaBodilsen

@Britelite

True.. Wolf3D have around 51 unique wall textures, not counting the halftones. so for all these to be prescaled in 16col 4bit textures, would take up 256kb of memory.

That is not counting, enemy's and objects.

so yes, if this technique is to be used, we would need to either reduce the number of textures, and/or introduce some form of smart loading, to only load the textures needed for a level.

Shouldn't mipmaps work and help a bit?
64x64 4bpl texture = 2048 bytes
51 textures x 2048 = 104448 bytes

51 textures x 2048 bytes each with mipmaps from 64x64, 32x32, .., 1x1 =104448+(1/3*104448)=139264 bytes

(!simplified!)

It could also potentially decrease visible sampling artifacts.

But the code would be a bit trickier I guess.

[LaBodilsen]

Sorry to say, but my idea will not work.

My first test of blitting 16x16px 4bpl bobs, with full cookie cut gave a disappointing result of only 150 bobs pr. frame. which mean it would need over 8 frames just to build the entire frame of 1280 bobs.

Some optimization could be made, but not enough to give a good result.

Back to the drawingboard.

EDIT: and finding this: Bob record only seems to confirm that using the blitter will be to slow to update the whole screen.

[LongLifeA1200]

It's time to focus on DanScott's idea/technique.

There's a another thread that discusses blitter vertical fill.

[britelite]

Originally Posted by LongLifeA1200

It's time to focus on DanScott's idea/technique.

Feel free to try it out, and tell us how it looks.

Anyway, I was actually toying around with the idea earlier myself, but I'm not sure if it would be that much faster, especially when you start adding sprites.

[LaBodilsen]

Originally Posted by LongLifeA1200

It's time to focus on DanScott's idea/technique.

There's a another thread that discusses blitter vertical fill.

Or ask KK how he did it.

Although it does seem that the rutine in the wildcat demo have some limitations. i notice it did not do to well with walls strips higher than the screensize, but that might be fixable. it does however run incredible smooth.
[ Show youtube player ] (pause at 1m37s)

[hooverphonique]

Originally Posted by LongLifeA1200

It's time to focus on DanScott's idea/technique.

There's a another thread that discusses blitter vertical fill.

Doing vertical blitter fill (2 xor'd sources, one destination) on a 320x256 3 bpl screen (and no other dma) takes more than 20ms, and slows the cpu a lot, so either low framerate or a small screen (or maybe even both) will be needed to do this in 16 colors (but the concept could probably work to render something non-textured, but with vertical strips colored according to distance from viewer/lightsource).