DooM XL ;-)

[Oswald]

I'm wondering about the "corrected distance" to defeat the fishbowl effect http://www.permadi.com/tutorial/raycast/rayc8.html

 

Instead of doing those extra calculations, why aren't they just using the difference offset between player and object?

 

ie - the greater of ABS(PX-OX) and ABS(PY-OY) where PX/PY are player co-ords and OX/OY are the wall co-ords.

 

 

because the distance of the wall slices and the player is only constant in orthogonal cases. imagine the wall shown on the link in a rotated version.

 

for a doom game you need the engine (vector?) from Numen with texture mapping. it would be around 1 fps or worse. textured floors needs more math as a rotzoomer alone fex.

[eru]

char aligned walls example from c64: http://noname.c64.org/csdb/release/?id=3248 it cheats as hard as it can, but manages to squeeze in colors in a high resolution.

Are you sure this is char-based? It seems like they have 4-pixel horizontal precision, unless they do some clever tricks there.

[Heaven/TQA]

the texture mapping looks "charbased" when i am looking at the rotating thing in the middle...

 

btw. i have to admit that i love smash design and AEGs gfx...

[Oswald]

Are you sure this is char-based? It seems like they have 4-pixel horizontal precision, unless they do some clever tricks there.

 

yeah, the color memory is char based, so they have to align the walls to it to avoid color bugs, if adding more than 4 colors.

[peteym5]

Are you sure this is char-based? It seems like they have 4-pixel horizontal precision, unless they do some clever tricks there.

 

yeah, the color memory is char based, so they have to align the walls to it to avoid color bugs, if adding more than 4 colors.

 

A char-mapped screen would take less memory and less cpu cycles to manipulate. It is a question of what mode you want to do, 5 colors with DLIs, GTIA 9 color, or even APAC with 256 color. Problem with APAC you will need WYSNCs for each line for a char mode and that holds up the CPU. Maybe you can do some game needed processing each WSYNC inside of the DLI. It would not be too difficult to keep a game running at 15 or 30 frames/sec.

 

You can do VBI processing in odd and even frames, or divide the processing over 4 frames. Even updating at 15 frames/sec is almost beyond human perception. Example Frame 1 do the player movement, 2 do enemy movement, 3 update screen, 4 do more stuff. I am doing a lot of dividing processing over two frames, and it is something nobody notices because it is still processing 30 frames/sec.

[Oswald]

Example Frame 1 do the player movement, 2 do enemy movement, 3 update screen, 4 do more stuff.

 

why dont you code Call of Duty 4 or Crysis for example? here's how it could be done imho:

 

decide wether 4 color 160x200, or some pmgs with dlis and color changing, or apac, or char mode, etc. then:

 

1. do the player movement

2. do enemy movement

3. update screen

4. do more stuff

 

thats all, its really simlpe

[Rybags]

I was thinking along the lines of charmap as well (in GTIA paletted mode), for the simple reason that drawing each line would happen a lot quicker.

 

Doing 64 or 80 vertical lines would consume a fair wack of processing power, even though it could be done with an unwrapped loop, along the lines of:

 

STA SCREEN,X

STA SCREEN+32,X

STA SCREEN+64,X etc.

 

Assuming you're near a wall which occupies 50 rows at a height of 80 pixels, that's 4,000 iterations in itself, which translates to at least 20,000 cycles.

 

Doing something in charmode could be a lot quicker. Intelligent "ordering" of the character set would allow the even lines to be just stored. Odd lines could be ORed over the existing character.

 

But, multiple character sets would probably be a must, considering the possible mixes of colour combinations and lines which only take up part of the character.

 

Using 8 colours (BG + 7 wall colours) would give 64 different mixes of full character height "stripes", leaving 64 characters which could be redefined (ie for softsprites, partial height lines). Probably sufficient to only need a different character set every 4-6 lines.

[eru]

My general impression about this discussion, as about many others in this forum: people talk too much, but nobody is doing anything.

It's easy to have vague high-level ideas, as you don't know what problems are really there until you start to work on it.

[analmux]

My general impression about this discussion, as about many others in this forum: people talk too much, but nobody is doing anything.

It's easy to have vague high-level ideas, as you don't know what problems are really there until you start to work on it.

 

Exactly, I feel the same, but I have something more to say.

 

Off course we can imagine a character based 3d engine. We can even use multiple charactersets/fonts. F.e. when doing 16 antic4 lines (or 8 antic 5 lines: seems more realistic to me) then we can use 16 (or 8 ) fonts.

 

I can imagine, when using a ray-casting method and a player that's at a fixed height above the floor (i.e. NO flying, NO crawling, always walking), then in certain horizontal bandshaped areas always certain gfx elements occur...thus, making specific fonts for each area.

 

The downside for this I think is to keep track of al the character-codes, for every point-of-view situation. You need some clever logic and table driven stuff I fear....but let's not say it's impossible.

 

But, rethinking a few things, I fear that charmode 3D engine is not that less time-consuming (less than full bitmap) as some like to think.

Edited January 24, 2008 by Analogue Multiplexer

[emkay]

But, rethinking a few things, I fear that charmode 3D engine is not that less time-consuming (less than full bitmap) as some like to think.

 

OK. Let's say it in this words:

 

IF I'd do coding a 3D game, I'd use double scanline PMg for the whole screen (Walls) . Doing all necessary calculations for the game. One DLI in the center of the screen gives a "in a room" 3D feeling then.

THEN... depending on the needed resolution, one can add graphics with single or double scanline mode....

-For the biggest screen size, a "Gr.7" mode is recommended.

-For Hires, and highest speed, someone may use 32 bytes width.

 

Charmode makes it faster, but it also makes the "Game-Resolution" worse.

 

Not to forget.... The ATARI has a real 4x4 mode... (gr. 5).... Together with the double scanline PM mode, the memory usage is about 1500 bytes to handle for a real fullscreen 3D... if the coder wants it.

Edited January 24, 2008 by emkay

[Rybags]

PMGs for the walls would be too 2600-like IMO.

 

Antic Mode 5 (Gr. 13 ) in GTIA mode might be the way. 80x80 pixel graphics with half the DMA penalty of a hires mode.

 

But... everything comes down to available CPU time. But, 25 FPS would be totally acceptable for gameplay.

 

 

It may well be that the raytrace operation becomes the bottleneck of the "system"- but there's always tricks like shorter "draw distance" that modern systems employ.

 

I've got some spare time - so might just get into it and produce a rudimentary engine to try some things out over the weekend.

[analmux]

Antic Mode 5 (Gr. 13 ) in GTIA mode might be the way. 80x80 pixel graphics with half the DMA penalty of a hires mode.

 

hmm, what's the use of GTIA mode antic 5? Antic 5 is a multicolour mode, thus GTIA 16color-decoding doesn't work fully....i.e. you must always use a hires gfx mode as a source (from antic) for full use of the 2 bitpairs sent by antic on the internal bus, for selecting one out of 16 gtia colours. In an antic-multicolour mode, the internal bus protocol is somewhat different, allowing effectively only 4 colours or something.

 

There is though another trick to get characters of the same size as antic5 in f.e. antic 2.

 

-always duplicate graphics lines (with double LMS pointing at the same part of screenmemory)

-on the even lines use a different font as on the odd lines.

 

this gives an effective screen of 8*16 (hirespixels) fontmode, thus ±40*12 characters, though, you won't solve the DMA problem then

Edited January 24, 2008 by Analogue Multiplexer

[eru]

But... everything comes down to available CPU time. But, 25 FPS would be totally acceptable for gameplay.

That's a good one.

If someone creates anything wolf-like with 25FPS (80x50 pixels in 4x4), I buy him/her a crate of good beer/wine.

It may well be that the raytrace operation becomes the bottleneck of the "system"- but there's always tricks like shorter "draw distance" that modern systems employ.

Really, you have no idea how time consuming ray-casting is comparing to drawing.

Having rays computed, drawing an untextured full-screen scene (80x50 in 4x4) is way faster than 1 frame (2000 bytes to fill, many with just a single STA), and even textured scene rendering takes around 1 frame with proper code.

 

Of course, you don't need to cast rays in the first place - just treat walls as rectangles in a 3D scene. I think that's how MAZE ( http://www.pouet.net/prod.php?which=18462 ) works.

Edited January 24, 2008 by eru

[emkay]

PMGs for the walls would be too 2600-like IMO.

 

 

Ofcourse the Resolution of the PM is rather low. With the used graphics you always can build the edges of the walls .... doors etc.

 

And, really, when using PM for the walls, the coder always has the chance to change the graphics modes per line ... either for temporary higher resolution or for higher speed.

 

 

...

[Rybags]

GTIA modes work in Mode 4/5.

 

Just that a remapping occurs with the bit-pairs.

 

Although, you lose some choices - but it's still usable.

 

Pixel value (bin)	AN2-AN0 pair values   Resultant display
0000					 000,000					 COLBK
0001					 000,100					 COLBK
0010					 000,101					 Colour 1
0011					 000,110					 Colour 2 (or 3*)
0100					 100,000					 COLBK
0101					 100,100					 COLBK
0110					 100,101					 Colour 1
0111					 100,110					 Colour 2 (or 3*)
1000					 101,000					 Colour 4
1001					 101,100					 Colour 4
1010					 101,101					 Colour 5
1011					 101,110					 Colour 6 (or 7*)
1100					 110,000					 Colour 8 (or 12*)
1101					 110,100					 Colour 8 (or 12*)
1110					 110,101					 Colour 9 (or 13*)
1111					 110,110					 Colour 10 (or 15*)

* = alternate colour available if high bit of character is set

Edited January 24, 2008 by Rybags

[Oswald]

maybe some words on the maths ? optimization of the raycasting engie ? how would you do sprites ? shading? etc ? handle enemy data on the map? how would you do some active lighting? screenmode is really one of the smallest problem. its only a tradeoff between colors/resolution/speed. the main question is how to render fast.

[Rybags]

Raycasting is like a line-draw routine. But you need to check for walls/objects at certain intervals.

 

Imagine the old Wolf3D map editor - it used charmode. Walls can only appear on certain boundaries.

 

If our "world" was represented in cells with 8x8 fine graduations, then we only need to test for a wall when (X AND 7)=0 or (Y AND 7)=0. For a little more cost, you can also do diagonal walls ((X AND 7) = (Y AND 7)) or (X AND 7) EOR 7 = (Y AND 7).

 

For each cell, you have a byte in memory to indicate what should appear in that part of the world.

 

Lighting? In it's simplest form, can be calculated for walls according to their distance. Possibly have N-S facing walls slightly brighter than E-W facing ones to aid perspective.

Floor/ceiling - I think that's been gone over - DLIs to change BG colour at specific intervals.

[eru]

maybe some words on the maths ? optimization of the raycasting engie ? how would you do sprites ? shading? etc ? handle enemy data on the map? how would you do some active lighting? screenmode is really one of the smallest problem. its only a tradeoff between colors/resolution/speed. the main question is how to render fast.

so true, and so in line with what I said before.

 

raycasting can be quite heavily optimized, but you still need quite a lot of computations, including a few multiplications for every ray. I really don't see a way around it.

 

the idea for sprites I had was to check the visibility of every sprite assuming there are no walls, get the distance, and for every drawn column compare it with the column distance, and only draw a sprite if it's closer.

 

shading is a relatively independent thing related to column rendering, not ray casting (once you know the distance from the POV, you can apply shading)

 

active lightning is interesting, but I guess still relatively easy, once you render a given position on the map, you can check its distance from a light source (and the angle of course), and apply the light. Here, I assume we ignore walls that might be in the way of the light.

[eru]

Raycasting is like a line-draw routine. But you need to check for walls/objects at certain intervals.

 

Imagine the old Wolf3D map editor - it used charmode. Walls can only appear on certain boundaries.

 

If our "world" was represented in cells with 8x8 fine graduations, then we only need to test for a wall when (X AND 7)=0 or (Y AND 7)=0. For a little more cost, you can also do diagonal walls ((X AND 7) = (Y AND 7)) or (X AND 7) EOR 7 = (Y AND 7).

 

For each cell, you have a byte in memory to indicate what should appear in that part of the world.

It's somewhat similar to line drawing, but trust me, if you do it like this, you'll be terribly slow.

There's a way to "draw" performing checks every map cell, not every map pixel.

Please, read the tutorial Oswald linked to above.

 

Floor/ceiling - I think that's been gone over - DLIs to change BG colour at specific intervals.

Won't work for the 16-shade GTIA mode.

[ZylonBane]

Just take the WAYOUT! engine and stick guns and Nazis in it. There, done.

[eru]

Just take the WAYOUT! engine and stick guns and Nazis in it. There, done.

I'm actually very curious how Wayout (and Capture the Flag) work - does anybody know, if it uses ray-casting? Or is it rather rotating walls in 3D and projecting them on the screen? Or something completely else?

 

Anyway, this engine is still a tiny bit too slow in my opinion.. 10 fps maybe? I can't check that, as Atari800MacX doesn't make movies

Still, Wayout rendering can be improved a bit: the author exploits the vertical mirroring of the screen, but doesn't exploit the fact, that the middle lines (how many varies) are identical... And it should be easily doable to make it twice the size just by using bigger pixels. Currently, it uses 2x1 (GR15) pixels, so 4x2 (2x1 in GR7) with the same speed should be doable. Interestingly, if 4x2 was used for tunnel rendering, then the on-screen objects can still be 2x2 - something impossible with GR9 and 4x4 pixels.

[Allas]

Way-out remember that an useful optimization is to prepare a DL as:

 

LINE1

LINE2

....

LINE39

LINE40

LINE40

LINE39

...

LINE2

LINE1

 

So, on screen game, upper area and bottom area are symmetric. You save a lot of drawing code. Only needs to change with DLIs the color background to get the effect of sky on the upper and floor on the bottom. I think Way-out works at 30fps at least, Capture the flag have 2 screens at the same time, it should be there 15 fps or 10fps

[eru]

Allas, the screen organization you described is exactly what is happening in Wayout, and, as I described, it's suboptimal.

And no way it's 30fps, since you can see separate frames of animation, which is pretty much impossible with 30fps. Please, someone with Atari800Win, record a movie and check for yourself.

[miker]

Well, in my opinion if there may be some 3D game, better concentrate on wolfstein-like engine first, rather than make some Quake V ( ) clone.

[Rybags]

Actually, a real-time RPG would probably work out much better than a Wolf3D or Doom game.