18 December 2017, 13:10 | #81 | ||
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 821
|
Quote:
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. Quote:
|
||
18 December 2017, 13:33 | #82 | |||
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,433
|
Quote:
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. Quote:
Quote:
|
|||
18 December 2017, 13:41 | #83 |
Registered User
Join Date: May 2014
Location: inside the emulator
Posts: 377
|
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. |
18 December 2017, 13:46 | #84 |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 821
|
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.
|
18 December 2017, 15:49 | #85 | |
Phone Homer
Join Date: Jun 2006
Location: 5150
Posts: 5,824
|
Quote:
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 Last edited by Retro1234; 18 December 2017 at 16:00. |
|
18 December 2017, 17:46 | #86 | |
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,433
|
Quote:
"Puppypebble2.5D" It would probably be closer to this C64-version than to the PC-version: [ Show youtube player ] |
|
19 December 2017, 05:45 | #87 |
Registered User
Join Date: Nov 2017
Location: Amiga Kingdom
Posts: 368
|
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. Last edited by LongLifeA1200; 19 December 2017 at 06:03. |
19 December 2017, 08:42 | #88 |
Registered User
Join Date: Dec 2017
Location: Denmark
Posts: 179
|
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. Last edited by LaBodilsen; 19 December 2017 at 19:32. |
19 December 2017, 08:57 | #89 |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 821
|
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
|
19 December 2017, 09:36 | #90 |
Registered User
Join Date: Dec 2017
Location: Denmark
Posts: 179
|
@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. |
19 December 2017, 09:44 | #91 |
Registered User
Join Date: Nov 2017
Location: Amiga Kingdom
Posts: 368
|
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.
|
19 December 2017, 10:05 | #92 | |
Moon 1969 = amiga 1985
Join Date: Apr 2007
Location: belgium
Age: 48
Posts: 3,914
|
Quote:
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 ? |
|
19 December 2017, 10:08 | #93 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,200
|
Because it is off-topic for this thread. This thread is about doing it on OCS A500/A1000.
|
19 December 2017, 10:24 | #94 |
Registered User
Join Date: Dec 2017
Location: Denmark
Posts: 179
|
|
19 December 2017, 15:39 | #95 | |
Registered User
Join Date: May 2014
Location: inside the emulator
Posts: 377
|
Quote:
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. |
|
19 December 2017, 19:14 | #96 |
Registered User
Join Date: Dec 2017
Location: Denmark
Posts: 179
|
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. Last edited by LaBodilsen; 19 December 2017 at 19:25. |
20 December 2017, 03:08 | #97 |
Registered User
Join Date: Nov 2017
Location: Amiga Kingdom
Posts: 368
|
It's time to focus on DanScott's idea/technique.
There's a another thread that discusses blitter vertical fill. |
20 December 2017, 07:31 | #98 | |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 821
|
Quote:
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. Last edited by britelite; 20 December 2017 at 07:42. |
|
20 December 2017, 08:51 | #99 | |
Registered User
Join Date: Dec 2017
Location: Denmark
Posts: 179
|
Quote:
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) |
|
20 December 2017, 11:00 | #100 | |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,643
|
Quote:
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
AmiWolf - new 68k Wolfenstein 3D port | NovaCoder | News | 324 | 21 June 2024 04:33 |
Amiga 1000 parallel port | desiv | support.Hardware | 12 | 16 May 2024 08:04 |
Wolfenstein 3D port for CD32 | earok | project.CD32 Conversion | 151 | 11 July 2018 02:33 |
The Amiga 1000 could of done a game like Wolfenstein in 1985 - shock! | AndNN | Coders. Asm / Hardware | 172 | 20 July 2017 17:48 |
AmiWolf - new AGA Wolfenstein 3D Port | NovaCoder | project.Amiga Game Factory | 100 | 16 September 2013 01:44 |
|
|