Raycasting demo

[GroovyBee]

JLP functionality is in the beta 4 emulator here. There is a CP1610 test suite in the source code *.zip src/jlp directory as well.

[JohnPCAE]

Looks good. It seems to have an occasional visual glitch in jzintv but I can try it out on PAL later.

 

Will it eventually become a game or is it just going to remain a tech demo?

 

It would be nice if someone could make a game out of it, but at this point I'm just trying to stretch the capability enough to see if it's even possible. Due to the Inty's limitations, there are some real drawbacks to using raycasting:

• The rendered image has to be monochrome without using sprites.
  
• Having sprites be partially obscured by walls is problematic
  
• The image uses 60 GRAM cards
  
• Rendering is slow
  

I have some thoughts on these issues, but I doubt I have the time to fully implement them:

• If you limit the viewing distance so that walls are never less than 1 card high, you could have the ceiling and floor be different colors
  
• You could have sprites be partially obscured by assigning each sprite its own GRAM card and blanking out columns in the card (though I don't know how quickly this could be computed)
  
• If you can detect where cards are either completely full or empty, you don't need a separate GRAM card for that block. It would mean allocating GRAM cards from a pool as needed, but it might speed up rendering and allow for a larger image (and free up cards for sprites). A larger image would also make the first point easier, though (increasing the minimum wall height).
  

At this point, though, the real performance killer is the multiplication routine, so none of this might be possible if a faster way can't be found. I'm taking another look at the table-based approach to see if some optimizations are possible. Unfortunately, I have another project that is suffering and I'm going to have to get back to it soon.

Edited April 26, 2013 by JohnPCAE

[GroovyBee]

Have you thought about using the coloured squares mode? You'd get almost full screen at the cost of looking more chunky.

[+DZ-Jay]

Have you thought about using the coloured squares mode? You'd get almost full screen at the cost of looking more chunky.

 

Not only that, but what about limiting the vantage angles? What if instead of an all around panoramic view, you present only a set of visible angles. Also, standardizing or limiting the playing field or wall layouts in some way may allow you to pre-compute the graphics of certain wall configurations at various angles.

 

-dZ.

[GroovyBee]

Due to the way raycasting works you can't really pre-compute much of what you see on screen unless the scene that you are looking at is very simple.

[+Gemintronic]

Just to throw around another concept: can't you fake raycasting with enough frames of pre-rendered maze sections like Phantasy Star for the Sega Master System? With enough bank-switching and EEPROM nothing is impossible

[GroovyBee]

Its an a good effect in Phantasy Star but there aren't many shades of each colour on the Inty and you have 64 programmable cards (tiles) for everything unique to your game so you'd need to watch your resource usage.

[JohnPCAE]

I thought about colored squares mode, but I figured the blockiness would look horrible as the resolution would only be 40x24 instead of 80x48. It does solve a bunch of problems, though. Does anyone want to take a stab at it?

[GroovyBee]

For a comparison there is MOOD on the C64 :-

 

http://www.youtube.com/watch?feature=player_detailpage&v=X3Oqz5WjDPI

http://www.youtube.com/watch?feature=player_detailpage&v=cceA9ZMtxaM

 

The other good things about coloured squares mode are that you aren't limited to VBLANK time to update the screen data and that you'll quarter the amount of data that you need to update per frame. Both of which will give you a FPS boost.

[JohnPCAE]

Colored squares is probably the way to go. Maybe I'll take a stab at that next. In the meantime, here is a version with possibly the ultimate in unrolling the multiplication routine. Performance is definitely a little better, enough that rendering might be the bottleneck now.

raycast.zip

[GroovyBee]

A game demo with a raycast engine for the Atari Lynx came out yesterday :-

 

http://atariage.com/forums/topic/211857-luchsenstein-3d/

 

The main play area looks to be around 50 "chunky" pixels across so there is hope for coloured squares mode .

[JohnPCAE]

Here's one where the side buttons will toggle to and from colored squares mode...

raycast.zip

[JohnPCAE]

Last one for tonight. Optimized and unrolled the colored-squares ray-drawing routine. Definitely boosts FPS a little

raycast.zip

[JohnPCAE]

Today's optimization: drawing both halves of a colored-squares card at a time. It eliminates the blanking step and the need for a read-modify-write process. No more flicker and better FPS

raycast.zip

[GroovyBee]

Coloured squares mode is looking good now. Maybe you should speak to intvnut about using the hardware features in JLP to accelerate the multiply/divide for ultimate performance.

[JohnPCAE]

It's probably at the point where using the features from a JLP cart are warranted. Here is a slightly faster version, but short of a breakthrough in the divide routine I've wrung about all I can out of it.

raycast.zip

[GroovyBee]

I finally got around to testing this on PAL hardware. In GRAM cards mode there are visual glitches in the top left bitmap as the walls are drawn and the same occasional screen stutter that you see in jzintv. Coloured squares mode works exactly the same as it does in jzintv.

[JohnPCAE]

I had a flash of insight and came up with a faster division implementation. The frame rate isn't bad, now.

raycast.zip

[+DZ-Jay]

I'm sorry, is it supposed to be in Color Square mode? I see it as before, in regular GRAM tiles.

 

Never mind. I forgot to hit the action button. DOH!

 

Looking good!

 

-dZ.

Edited May 15, 2013 by DZ-Jay

[JohnPCAE]

I found a way to make a couple of improvements to the raycasting algorithm:

 

- If a ray intersects a wall, don't test orthogonal walls beyond the distance to the wall that was found

- If you use the keypad to limit the view distance, don't test for walls beyond that distance

 

The first change improves the framerate in all cases and the second one only if you limit the viewing distance. However, the default distance when starting up is 32 units, which covers the entire maze. Even a modest setting like 6 units gives a huge improvement in frame rate.

raycast.zip

[JohnPCAE]

Bleh. I found a bug in my new division routine and had to make a small change. It's a teensy bit slower, but not so much that it should be noticeable. At least it's correct, now.

raycast.zip

[JohnPCAE]

Lots of little changes for more speed

raycast.zip

[JohnPCAE]

I got some more speed by skipping a couple multiply operations when they're not needed: if you're moving in a straight line I can reuse the same dx,dy values, and if you're turning in place they're zero. I also squeezed a little speed out of RenderCS(). A cart with multiply/divide support would definitely help, though...

 

(if anyone is contemplating a coprocessor cart, my wish list would be the following:)

 

- 16/32 fixed-point math support (everything that an 8087 can do)

- IEEE 754 32-bit math support(everything that an 8087 can do)

- 2x2, 3x3, 4x4 matrix support for fixed and floating-point math

- Advanced bit shift and rotate support

- Special support for shifting GRAM cards in 2 directions

 

I can dream...

raycast.zip

[JohnPCAE]

I found a bug in my multiplication routine and fixed it (multiplying by 0xDD was actually multiplying by 0xDB).

 

I also performed some analysis on some of the potential forms for some of the sub-multiplications and managed to find faster alternatives for quite a few (the higher-end ones, e.g. 0xC0 and up). I've included comments in the source showing the analyses, for anyone who is curious.

raycast.zip

[JohnPCAE]

A little more multiplication goodness...

raycast.zip

Edited June 7, 2013 by JohnPCAE