Jump to content
IGNORED

Raycaster for the 2600 (Discussion) (2014)


Gip-Gip

Recommended Posts

Hello! this is my first thread on the Atari age forums, inspired by another thread made about 7 years ago by grafixbmp(which sadly nothing happened besides a few concepts and it has been 6 years since anyone but me posted something on it). but I hope this thread will go past the discussion phase and maybe even accomplish a hovertank style game!

Link to comment
Share on other sites

I'm used to batari basic and have a little bit of experience with nasm so i suppose it's similar to dasm(looking for the tutorials). as far as concepts go a simple hovertank style game with simple 1(or 2)frame graphics for enemies (and prisoners)and minimal hud would be pushing the system to the limits but would be playable as far as the frame-rate goes(10-12 fps, if programmed correctly). not going for a doom or even a catacomb 3d theme because of system limitations though. coming up with concept art.

Link to comment
Share on other sites

as far as concepts go a simple hovertank style game with simple 1(or 2)frame graphics for enemies (and prisoners

Objects in the maze and how many frames of animation they have aren't such a big problem, because you can pre-calculate some of the scaling and use the hardware scaling (sprites can be made twice and 4 times wider with no effort, and vertical scaling is simple) to complete the effect.

 

and minimal hud

The HUD matters even less, because it can be completely separated from the gameplay window and would be drawn with dedicated code.

 

would be pushing the system to the limits but would be playable as far as the frame-rate goes(10-12 fps, if programmed correctly)

I've programmed a raycaster for the NES (video) and in that program, these are the 4 main things responsible for keeping the CPU busy:

 

1. calculating how far the player is to the next grid (requires 2 multiplications, one for each axis);

2. extending the rays (there are 2 rays per angle, one for each axis) until they hit walls (bunch of additions);

3. calculating the height of the wall based on its distance from the player (1 division);

4. scaling the texture to fit the wall height that was found (bresenham algorithm with a lot of bitshifting);

 

All of these steps need to be done for each wall stripe (there are 28 in my raycaster), so you can see this adds up to a lot of multiplications and divisions, which the 6502 is not very good at. For the 2600 you would certainly skip the texturing and use flat-colored walls, so that would buy you some processing time. The main problem I see is that because of the rudimentary video hardware of the 2600, the CPU has to actively interact with it to generate a picture, so you only get a small portion of the frame's time for actual game calculations (unlike the NES, where the CPU is available for processing game logic while the picture is rendered by the PPU), so you have very little time to do a whole lot of math.

 

Another problem is the color limit of the 2600. You can easily change colors vertically, but not so much horizontally. So unless you want to rotate your TV (like Merlin's Walls does, while still managing to look terrible), you'll have a very hard time getting more than 2 different wall colors per frame, and that's if you alternate the colors with blank scanlines. also keep in mind that at such low resolutions, it's really important to differentiate perpendicular walls, usually by making them darker, so you'll want to make more scanlines black for this purpose too.

 

The small amount of RAM will also be a problem, because there just isn't enough of it to store a complete screen, let alone a buffered one you can update behind the scenes. There is enough memory to store the height of each wall slice and their colors, but you'll have to be very creative to find a way to convert that into display data in real time (that would be a job for your kernel).

 

I believe that this can be done, but you'd have to think really hard about how to implement everything. Pre-calculating as much as you can and using look-up tables (which means a big increase in ROM size) instead of processing data in real time is the key here.

Edited by tokumaru
  • Like 1
Link to comment
Share on other sites

Thank you for pointing those things out! I'm thinking of ways a full real-time game could be made(scanning one column of a wall and choosing one pixel of the column according to the scan-line and clearing the others might work) but if it comes down to it pre-made walls and pre-scaled sprites is an option.

 

PS:

The raycaster you made looks great :)

Edited by Gip-Gip
Link to comment
Share on other sites

in your example you would not even notice when you move forward/backward.

Maybe it would be sufficient for your ideas to restrict yourself to a number of fixed screens like in the old

dungeon-style games? No scrolling but a screen like yours, one with turn left, turn right, opening left, opening right etc.

Then you could get away with probably some extra-ROM and pre-defined dedicated kernels to render you intended backgrounds allowing for some/any simple(!) "sprite" being drawn as well optionally.

I can imagine that much better than a raycasting engine and it would still look fresh and nice on the 2600.

Link to comment
Share on other sites

Only if the scrolling grid lacks perspective :)

 

 

Roland, awesome Ballblazer demo! :) Are you using tables to do the calcs or raycasting in real time?

Thanks,

 

No tables for the playfield. Just lots of LDA/STA COLUBK for drawing the playfield. The cycles between consecutive STA COLUBK's gets one more for each 2 scanlines down. That's how the diagonals are drawn. All hardcoded.

The skewing (move left/right) is done between two scanlines with a bresenham calculation (A = A + skew_value, skip a cycle if carry is set., More skew_value is more carries is more skipping is more skewing).

The horizontal lines are drawn with a divide by 2 (LSR) routine, so horizontal lines/transition-between-tiles are drawn at scanline 16, 8, 4, 2, 1, 0. Then start with 15 etc. (the antialiassing kernel uses rest values for antialiassing)

 

I concur with ZylonBane, the kernel is totally different from a raycasting (if I understand rayscasting enough).

My engine doesn't rotate, it's just a floor and there are no vertical objects but the rotofoils. In a raycast engine everything is a vertical object and there isn't a floor. Besides that, the LDA, STA COLUBK pattern doesn't fit anywhere in a raycast engine.

 

Maybe if you rotate your monitor...

Edited by roland p
  • Like 1
Link to comment
Share on other sites

So, lets say we have a kernel with a 32 column playfield. That's 32 rays to draw. This is an 8-bit system so the dungeon map would be at best 16x16.. right? And how many degrees of rotation would we have to support? I suppose the path they would have to traverse would be hard coded somehow.. my brain hurts.

Link to comment
Share on other sites

The map size doesn't necessarily have to be limited as such but 16x16 might be "nice" in that 8 bits allows coordinate to have a tile and fractional value.

 

The raycast can use any angle you choose between pixels but it's probably easiest to do represent a circle not in degrees but some multiple of 2, e.g. 256 steps around a circle gives 64 per quadrant (vs 90 Degrees).

 

When doing the raycast you could choose to do each ray as a single step, or 2 or 3. 3 steps * 32 pixels = 96 steps which represents a 135 Degree viewport. 4 steps * 32 pixels = 180 Degree viewport.

Of course the pitfall of having larger steps in the raycast is that it's possible to miss wall segments over medium/large distance.

 

I remember using the Wolf3D editor in the 90s - a pitfall there was that large open areas could just make the game chug or even hang. Such problems can be overcome by using a finite number of casting steps.

 

Doing all this with 128 bytes... I don't know really. Probably a good idea to develop for a cart scheme that includes a bit more RAM.

Link to comment
Share on other sites

Thanks,

 

No tables for the playfield. Just lots of LDA/STA COLUBK for drawing the playfield. The cycles between consecutive STA COLUBK's gets one more for each 2 scanlines down. That's how the diagonals are drawn. All hardcoded.

The skewing (move left/right) is done between two scanlines with a bresenham calculation (A = A + skew_value, skip a cycle if carry is set., More skew_value is more carries is more skipping is more skewing).

The horizontal lines are drawn with a divide by 2 (LSR) routine, so horizontal lines/transition-between-tiles are drawn at scanline 16, 8, 4, 2, 1, 0. Then start with 15 etc. (the antialiassing kernel uses rest values for antialiassing)

 

I concur with ZylonBane, the kernel is totally different from a raycasting (if I understand rayscasting enough).

My engine doesn't rotate, it's just a floor and there are no vertical objects but the rotofoils. In a raycast engine everything is a vertical object and there isn't a floor. Besides that, the LDA, STA COLUBK pattern doesn't fit anywhere in a raycast engine.

 

Maybe if you rotate your monitor...

 

IMO your process for creating those angles and the skewing sound like basic raycasting - drawing rays with a starting point and a direction using calcs to create 3D perspective.

Link to comment
Share on other sites

IMO your process for creating those angles and the skewing sound like basic raycasting - drawing rays with a starting point and a direction using calcs to create 3D perspective.

Your opinion is wrong. Raycasting isn't just drawing lines, it's checking for collisions. That's the entire point of it. You cast one "ray" out into the world for each column of the output image, then track how far it goes into the world before it hits something. This is absolutely nothing like how an angle-locked perspective grid is drawn.

Link to comment
Share on other sites

Since my browser is being wonky and won't show all replies:

There was a crude raycaster in the works by the Ebivision guys, and all that I saw of it was an old Quicktime movie file. I have no idea if it was even real, but he claimed to get around 5-7 fps with a 8x8 1-bit texture-mapped orthogonal maze. Not very good, but not bad either.

Link to comment
Share on other sites

So, lets say we have a kernel with a 32 column playfield. That's 32 rays to draw. This is an 8-bit system so the dungeon map would be at best 16x16.. right? And how many degrees of rotation would we have to support? I suppose the path they would have to traverse would be hard coded somehow.. my brain hurts.

IF a real-time racaster was coded somehow, i'm doubting it would use all 32 columns in the playfield. Most likely 16 columns, using 2 columns rows per scanline. it wold be crappy looking, but if the maps made for it have wide hallways you won't notice to much.

 

The only problems I see with the way roland p's game(and battelzone for the 2600) renders is that it makes map creation way more difficult(if not impossible) and like mentioned before, It's not a raycaster.

 

 

Maybe something that creates only an outline? Like faceball on the gameboy, but with lines instead of filled polygons. Would that be feasible?

It's not a bad idea. It does get rid of the need to make the walls different colors(because they're all outlined), so it wold save me from having to turn my 70 pound tv sideways every time I want to test it. However if you were talking about the sprites then it is completely unnecessary, unless you want them to match the theme.

Edited by Gip-Gip
Link to comment
Share on other sites

Your opinion is wrong. Raycasting isn't just drawing lines, it's checking for collisions. That's the entire point of it. You cast one "ray" out into the world for each column of the output image, then track how far it goes into the world before it hits something. This is absolutely nothing like how an angle-locked perspective grid is drawn.

Zylon,

the same process by which Roland draws the rays and makes adjustments in perspective could be used to check for collisions on the field - they are the same points ;)

Link to comment
Share on other sites

the same process by which Roland draws the rays and makes adjustments in perspective could be used to check for collisions on the field - they are the same points ;)

Inasmuch as you've made it abundantly clear in the past that you don't really grasp "technical" things, and just latch on to certain key words and imperturbably pretend that you understand them, I'm going to try to explain this anyway:

 

Raycasting works by tracing imaginary lines in WORLD space. The line traverses the internal dataset used to represent the world geometry, looking for collisions.

 

Rendering a grid works by drawing a literal line in SCREEN space. There is an actual, visible line drawn.

 

Other than lines being involved, these two techniques have NOTHING in common. If your comprehension of this subject extended in any way beyond "Lines! I know what lines are!" then this would be obvious to you.

  • Like 1
Link to comment
Share on other sites

Uh, you mean the same Ebivision that published Merlin's Walls?

Yep, those guys! It would be cool to have seen a texture-mapped maze in a 2600 game, but the framerate was so terrible that it just wasn't that feasible to make into a game (unless you have a lot of patience).

 

Edit: Since I sadly worked with raycasters, I'll give some "mansplaining" insight:

The tradeoff of raycasters is speed vs memory. Basically, the less memory you have, the more real-time procedural work you will have to do, which slows the performance down dramatically. However, if you have enough memory, you can generate fixed procedures based on the viewpoint (and the resolution of the viewpoint) and keep the memory offsets stored, thus speeding up rendering. Basically, a simple function-based LUT for each column slice you have. That's going to be a Herculean effort to fit in VCS RAM, if it were even possible to generate these at all - it'd probably be best to statically set them in the code.

Edited by Csonicgo
Link to comment
Share on other sites

Even if it were possible to run a full frame-buffered texture mapped ray casting engine on the 2600, it seems unlikely you'd want to, given the abysmal horizontal resolution. Even Project M on the 8-bit Atari computers is scraping the lower bounds of what's visually acceptable, and that's running twice the horizontal resolution and 16 times the color depth.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...