creating a new 3d graphics engine for the Atari 2600 (talking phase)

[+grafixbmp]

I have seen 3d game engines done for many systems over the years: nes, gameboy(faceball) gameboy color(tech demos one in particular with mode 7 on a GBC) and many other low end systems including the intellevision (sewer sam I have a copy on cartridge) some games for the Atari 2600 have also done crude 3d engines. Some come to mind like starwars the arcade game and Buck Rogers. But I thought about doing something more that is a bit more free with gameplay and movement. establishing this game engine concept is as follows:

utilizing a section of memory in ROM that has 60 bytes you can acheive a 12 by 10 block grid with 16 possible items/things or other objects. Then using a mathematical triangulation with an angular rotation algoritum which will calculate the distance and screen loation of the posible items in the field of view and pull from memory in rom the images needed to display them. This also will take into acount the distances and resize the images for closer or far away vewing. Now this is still based on a 2d playing field but with screen tricks that fool the eye, you can acheive a false 3d effect similar to mode 7 for the SNES. Because the Atari 2600 displays graphics on a scanline by scanline basis, a sudo 3d landscape could be acheived. I have been looking at several triangulation methods and decided to call upon the experts here.

 

There is no need to talk discouragement here. I realize this could be near impossible but nothing ever gets accomplished with negativity. I also thought about using a 30 Hz screen flicker for the BG to acheive more onscreen things at once. I will try to inclose some images for a sudo idea of what I mean. The main imabe view DOES NOT conform to the Atari 2600 graphical specifications yet. This is just to show proof of concept visualy.

3datari2600_engine.bmp

 

 

3datari2600_engine_demo_screenshot.bmp

 

Major Update to this Topic: Me and Mindbleaach have been focusing our efforts on a DOOM style engine that would run at 12 FPS. This may not ever work but we are optimistic and with some thinktanking, have introduced some unique ways to speed up processes. Could use some input from anyone willing to read through posts on page 2

 

Here is a new mock image that is also on page 2 to get the juices flowing

 

This new one is more complexed that what we are shooting for but it is just for an example. This is the first screen you see at the bigining of DOOM first level 'The Hanger'

3datari2600_engine_demo_screenshot.bmp

Edited May 14, 2008 by grafixbmp

[Heaven/TQA]

i am sure that the "mode7" like plainfield can be done as it a simple lookup table issue. as the 2600 is building the display on a scanline basis should be doable... rotating stuff will be much harder i guess...

[mos6507]

You can do some planar pseudo-3d effects but not a general purpose engine. Look at things like Beamrider, Buck Rogers Planet of Zoom, Solaris, Mindmaster. Tod Frye claimed to have a beta of Ballblazer for the 2600 going. That would have been fun to see.

[supercat]

You can do some planar pseudo-3d effects but not a general purpose engine.

 

Using 4A50, something like Battlezone (screen limited to 96 pixels wide) might be workable. I've already thrown together a spinning text demo which shows the words "CUTTLE CART RULES" around a circle; the joystick can rotate the thing smoothly. Plotting lines would be a little harder than plotting pixels, but there are probably ways to make it work. If the target frame rate is 10fps, it may be possible to do in-kernel most of the work of clearing the screen between frames; a 10fps rate should be quite playable.

[+grafixbmp]

I updated the mockup image with the guidelines and color pallette of the atari 2600. this may help the look of the example. also I was thinking about a 32 degree sectioning of the players rotation and a set angle of the field of view.

3dengine_atari2600.bmp

[+grafixbmp]

You can do some planar pseudo-3d effects but not a general purpose engine.

 

I've already thrown together a spinning text demo which shows the words "CUTTLE CART RULES" around a circle; the joystick can rotate the thing smoothly.

I would love to run that demo and see what you came up with.

 

The basic layout I was shooting for was a floor-like grid made up of 12x10 spaces.

Each grid section can be 15 diffrent things. THese things have diffrent atributes and fuctions in gameplay. They have their screen imaging data stored in the ROM and are called upon by one of the possible 15 values (incidently if the value is 0, then nothing is done (blank area or grass))

The boarders are outlined with one of the missles and possibly some of the BG if needed.

The actual ground effects are done with a blue scale and gray scale color pallette. Each of which alternate for the BG pixle colors per framew or at 30 Hz intervals.

The point of view from the character on screen can rotate by 32 angle positions or a 5 bit number allowing for 8 per 90 degree section. 64 possible angles would be cooler, but I didn't want to get my hopes up. Based upon the current angle as center, a field of view angle (which is a perminant value) indicating the width of the screen relative to the grid is calculated for the center of location on the grid and the angle of field of view or direction facing.

Now the tricky part is organizing all this data about the grid, field of view tiangulating distance of all visible objects and calling up the data to display thoes objects based upon their horizontal location and distance frorn the location of view on the grid. this requires a set of equations that could efectivly display at a visible screen change every 4 frames or 15 frames a second. 30 framess a second would be cool. but 15 is probably more realistic

[Nognir]

I am actually exercising in batari basic a bit, but I really don't know if something like that is doable.

But the mockup picture looks very nicely and if this is really doable, then it would look very impressing.

Keep up the work!

[Bucket]

utilizing a section of memory in ROM that has 60 bytes you can acheive a 12 by 10 block grid with 16 possible items/things or other objects. Then using a mathematical triangulation with an angular rotation algoritum which will calculate the distance and screen loation of the posible items in the field of view and pull from memory in rom the images needed to display them. This also will take into acount the distances and resize the images for closer or far away vewing. Now this is still based on a 2d playing field but with screen tricks that fool the eye, you can acheive a false 3d effect similar to mode 7 for the SNES. Because the Atari 2600 displays graphics on a scanline by scanline basis, a sudo 3d landscape could be acheived. I have been looking at several triangulation methods and decided to call upon the experts here.

This sounds a lot like a raycasting engine. Games like Wolfenstein 3D, Doom and Hexen use this engine. If you're unfamiliar with raycasters: they're like raytracers (those non-realtime super-accurate engines used for CGI), except instead of calculating every pixel, it does a whole column at a time. And they don't have those fancy light-diffusing calculations. There's a tech demo out there for the 2600 that I can't remember the name of, but it's a pretty simple example. It even requires you to sit your TV on the side because it's faster to do rows than columns on the 2600.

 

A great thing about raycasters is that they can be tweaked to have a very convincing 3D look. Even better is that there's a TON of info on the internet on how to make one. Anyway, this might all be painfully obvious to everybody, so ignore me.

 

As an added bonus, here's a raycaster for the NES:

[+grafixbmp]

utilizing a section of memory in ROM that has 60 bytes you can acheive a 12 by 10 block grid with 16 possible items/things or other objects. Then using a mathematical triangulation with an angular rotation algoritum which will calculate the distance and screen loation of the posible items in the field of view and pull from memory in rom the images needed to display them. This also will take into acount the distances and resize the images for closer or far away vewing. Now this is still based on a 2d playing field but with screen tricks that fool the eye, you can acheive a false 3d effect similar to mode 7 for the SNES. Because the Atari 2600 displays graphics on a scanline by scanline basis, a sudo 3d landscape could be acheived. I have been looking at several triangulation methods and decided to call upon the experts here.

Anyway, this might all be painfully obvious to everybody, so ignore me.

 

As an added bonus, here's a raycaster for the NES:

 

No by all means give me as much info as you can. And thanks for the youtube link. That is nice. I hope that gets finished. However with the thoughts I had, I was just thinking aobut the ground alone no wals or sides just a flat field layer with objucts on it. I figure that with a vertical and horizontal calculations with a 90 degree angle you can get the hypotenuse (probably spelled incorectly) and know how fdar away it is and with that know the angle for your current location then i\using that angle calculate in relationto the current facing angle and know how far left or right from center to be and the hypotenuse lenght gives your distance from your player then just look up the graphics table from memory for that object and your are done (with that one item alone. still thinking 15 fps is acheivable with nomore than 8 objects on screen at once excluding the border line.

[supercat]

This sounds a lot like a raycasting engine. Games like Wolfenstein 3D, Doom and Hexen use this engine. If you're unfamiliar with raycasters: they're like raytracers (those non-realtime super-accurate engines used for CGI), except instead of calculating every pixel, it does a whole column at a time. And they don't have those fancy light-diffusing calculations. There's a tech demo out there for the 2600 that I can't remember the name of, but it's a pretty simple example. It even requires you to sit your TV on the side because it's faster to do rows than columns on the 2600.

 

There's a game called 'Merlin's Walls' which is a sideways walk-around-the-maze for the 2600. Perhaps you're thinking of that.

 

I did a pseudo raycast/texture map demo on the 2600 (no expansion RAM needed!) which showed a "SUPER CAT!" logo. Using that technique, it might be possible to manage a sideways 'Wolf3d' type game using a small (48 pixel) window, though showing any monsters at the same time would probably necessitate the use of flicker, blinds, or flicker-blinds.

 

I suppose you could say the 'sideways' requirement is because it's faster to work with things that are sideways, but saying it's 'faster' is like saying that a fired bullet is 'faster' than a snail. Given six bytes of data, the 2600 can easily display them horizontally; it can easily do this once per scan line, so it's easy to show 64 separate groups of six bytes of data (one group per scan line). There is no practical way to show on each scan line one pixel from each of 48 groups of data. That one just doesn't work.

 

Given expansion RAM, it may be possible to do a sideways texture-map demo. Rendering a 48x64 window would require 3072 ROL accumulator and 3072 ROL ZP instructions, among other things. Assuming 33% CPU availability, that would represent more than 1/20 second worth of execution for those two instructions alone.

 

That might not be totally unworkable, if one were targeting a 10fps frame rate (I would expect most of the time would be spent executing the instruction sequence:

  lda ray_mem_l,x
 sta rowptr
 lda ray_mem_h,x
 sta rowptr+1
 ldy #0
 lda (rowptr),y
 rol
 rol buff+0
 rol
 rol buff+1
 rol
 rol buff+2
 ...
 rol buff+7
 iny
 lda (rowptr),y
 rol
 rol buf+8
 rol
 rol buf+9
 rol
 rol buf+10
 ...
 iny
 lda (rowptr),y
 rol
 rol buff+56
 ...
 rol
 rol buff+63

Clearly there are a fair number of instructions besides 'rol's, but the time required for the rol's will clearly dominate.

 

BTW, another advantage of doing things sideways was that color may be assigned on a per-row basis. Thus, one would be able to have different wall panels with different colors, greatly enhancing things. I wouldn't require the user to turn things on his head, though. Instead, I'd set the game in a tall but narrow space station with nothing interesting on the left and right walls.

Edited August 14, 2007 by supercat

[+grafixbmp]

This sounds a lot like a raycasting engine. Games like Wolfenstein 3D, Doom and Hexen use this engine. If you're unfamiliar with raycasters: they're like raytracers (those non-realtime super-accurate engines used for CGI), except instead of calculating every pixel, it does a whole column at a time. And they don't have those fancy light-diffusing calculations. There's a tech demo out there for the 2600 that I can't remember the name of, but it's a pretty simple example. It even requires you to sit your TV on the side because it's faster to do rows than columns on the 2600.

 

There's a game called 'Merlin's Walls' which is a sideways walk-around-the-maze for the 2600. Perhaps you're thinking of that.

I played that merlin's wals and was rather impressed. It had full rotation which was cool. I also tried skeleton and likedit too.

 

However, both of thoes relied on their 3D being portrayed by the wals alone. I was looking more to the floor alone.

 

I think I have refiened my thoughts a bit more. the purpose of the 60 bytes is to layout all items,objects and barriers on a grid so that they are relative to each other.

 

this consists of 16 posible outcomes of each individual section of the grid. ex: tree, water, hole, grass (0000), item on ground, item in air, etc. each thing is displayed in difrent ways using the atari's graphic resources. The 15 difrent thigs have data sections in memory that can be called upon to show them anywhere on the screen (in the lower portion of the screen. This graphical data isn't just one thing, but many scenarios of that object depending on where it is relative to your location.

 

I will go through a walk through of execution step by step (just basic design) first your character will always be drawn on screen in the middle lower portion of the screen with player 0 at twice the width, or at 16 colour clocks width. then a starting location is preset for that particular grid you start out with along with a facing angle. I think that 64 angles is beter for a smoother rotation animation. so lets say you are facing up. Then that means any object up from where you are will have a distance of 1,2,3,4,etc . however if there is an object 3 up and 2 over left, then you calculate the hypotenuse by using 3v and 2 h along with 90 degree angle. when you get the hypotenuse (longest side of a triangle), you know exactly how far that object is from your position and at what angle off from your curent angle it is. Lets just say it is 10 degrees to your left for example.

 

If your were facing at 45 degrees left, then you would minus 10 from current facing angle to get its location relative to yours. But the angle is needed, to know how far to the left or right of the screen to place the object being calculated. the hypotenuse is for the distance away from the player. The distance is used, to know where from that objects graphics library to pull in order to show the apropriate data of the object on the screen. When moving forward, anything on screen doesn't need to be calculated for angle anymore, untill new objects come into view from a distance . Just scroll down the screen at an increasing rate.

 

Jsut as the atari has horizontal display triggers and sub horizontal movement, so will this engine. for which ever grid section you are located, your character has certain atributes. x,y, facing angle, 2 bit offset . the 2 bit offset is for smoother forward movement and all polly calculations are adjusted by this offset. so say you are at block 2,3 facing at 210 degrees and have an offset of 1. This means that your are farther away from an object than if you had an offset of 3.

 

if you were moving forward then you would have to go offset 0,1,2,3 before moving to the next grid block and then start back at 0 again. this offset does change patterns depending of your angle of movement. IF your happen to graze the edge of a grid section because of an obscure angle, there is a look up table of values that puts a pattern to the offset table. like 0,1,2,3,2,3,0,1,2,3,2,3 and so on. This patern is just to adjust your forward movement so it stays smoother. The hardest part is programing all of this to work together so that your can turn and still move forward at the same time. And at any given time only 8-10 object should be calculated at once. Any more and they may not be displayable due to nomore time for calculations, display atributes of the TIA can not accomodate them, and possibly other reasons. So the playing field has to be layed out acording to this plan.

 

Also, this display system has to establish boarders of the playing field and tis is achieved through a 2 frame flicker of one of the missles and the background itself. This is also ging to be hard to do. It would be a smart display calcualtion for the boarder of the playfield.

 

The coolest part of all this is that when you have a fully working engine, then all you need for diffrent levels is: 60 bytes for playingfield grid, starting location, starting facing angle, player atributes (life, abilities) you could have like 5 diffrent levels and plently of replay value.

 

There could also be other changes like diffrent scrolling backgrounds. diffrent ground color levels, slower overall movement along with slower vertical movement of player and you got swiming in water (with suitable animation to reflect that).

[Mindbleach]

Love the topic. Seeing hardware pushed to its limits and beyond is a personal interest of mine.

 

 

Here's a mockup for an alternative take, really a few ideas pushed into a single image. First is the perspective change - basically, eliminate the background. This makes sprite design more challenging and requires you to draw more lines of faux 3D, but it does limit your view distance. Additionally, since it's halfway to overhead, there's fewer sprites per scanline and thus less need for flickering. Shown here is a tank (the player) turning and firing his guns, hitting one target and moments away from being hit by another. Bullets will mostly be coming at you or from you, again making per-scanline tweaking with the balls and missile possible.

 

You mentioned floor-based 3D as opposed to wall-based 3D, and I felt that a grid was appropriate for that. The grid is accomplished with the foreground color (the player's shots don't match, my mistake), changed like the background color according to a table. Seen here, the changes are staggered ground-line-ground-line to suggest a finer gradient than the 2600's palette really allows. The water idea was too good to eschew, though, so it stays in as an interlaced effect. Additional uses for colored patches of ground with different effects: sand that slows you down, rocks that stop you cold, black minefields that occasionally blow you up, and green zones that repair you. The gradient effect could be further enhanced by using a different hue for these alternate scanlines.

 

This inaccurate mockup is based only on the 2600's drawing limitations, not on its ability to compute and store the information needed to draw it.

[Artlover]

So someone make Doom 2600 already!

[+grafixbmp]

This mockup you did is rather impressive. I like the vew and angle for this. However, one of the reasons I was going with a sort of ground and distance look is so that in the distance are of the screen, you could have less on screen graphics and more game code during that part.also. using a 30 hz flicker gets you more colors and spreads your code out more so that more can be dine with less.

 

With a decent sudo 3d engine based upon all this, the old hoax of Duke Nukem forever could be doable

Love the topic. Seeing hardware pushed to its limits and beyond is a personal interest of mine.

 

 

Here's a mockup for an alternative take, really a few ideas pushed into a single image. First is the perspective change - basically, eliminate the background. This makes sprite design more challenging and requires you to draw more lines of faux 3D, but it does limit your view distance. Additionally, since it's halfway to overhead, there's fewer sprites per scanline and thus less need for flickering. Shown here is a tank (the player) turning and firing his guns, hitting one target and moments away from being hit by another. Bullets will mostly be coming at you or from you, again making per-scanline tweaking with the balls and missile possible.

 

You mentioned floor-based 3D as opposed to wall-based 3D, and I felt that a grid was appropriate for that. The grid is accomplished with the foreground color (the player's shots don't match, my mistake), changed like the background color according to a table. Seen here, the changes are staggered ground-line-ground-line to suggest a finer gradient than the 2600's palette really allows. The water idea was too good to eschew, though, so it stays in as an interlaced effect. Additional uses for colored patches of ground with different effects: sand that slows you down, rocks that stop you cold, black minefields that occasionally blow you up, and green zones that repair you. The gradient effect could be further enhanced by using a different hue for these alternate scanlines.

 

This inaccurate mockup is based only on the 2600's drawing limitations, not on its ability to compute and store the information needed to draw it.

[Mindbleach]

The fullscreen 3D look was intended to cut down on the need for flickering and put a realistic, concrete limit on draw distance, but I can understand the desire for a few hundred extra cycles every frame with as many sprite objects as you want.

 

I haven't seen true Mode 7 implemented on a GBC, by the way, and I'd very much like to see the demo you mentioned in the first post. I've seen some great fake 3D by Phantasy and Tiertex, plus the proof-of-concept raycaster in Back From Earth, but not the iconic planecasting effect. A note on that, by the way: you can shrink a whole lookup table to half as many entries as you have pixels to render. 40 pixels wide for 90 degrees FOV? Then store rays for all 360 degrees, preferably as a strided list of shrinking concentric circles, and rendering the playfield in any direction is a matter of choosing 40 entries in each row of the lookup table. Obviously you don't need all 360 degrees, since a circle is concentric about both axes - subtract x & y values where necessary, and you need only store 90 degrees. It's also concentric about x=y, so you can halve that to 45 degrees if you can elegantly swap x & y values as needed. You could have a convincing 3D plane with just over 1000 entries - still not a slim structure to store, but there's room to shave off more with cheap bitshifting multiplication & division.

[+grafixbmp]

I am wanting to say that I had found that demo a long time ago at www.devrs.com I don't know this 100% but it is the only place I can think of. I am looking it over one last time to see if it is still there. they have quite a bit of things for the gameboy, the advance, GP32, Cybiko and the NGP.

[Ben_Larson]

i think it is possible to do a wolfenstein 3d type game on the atari 2600...maybe not with texture mapping, but i think at least with the walls. but has anyone considered how the multiplication/division is going to be done for the rotation and projection? i assume using logarithm lookup tables (i.e. like a slide rule in ROM), but i'm not sure how big it would need to be to avoid too much error in the results...

 

This inaccurate mockup is based only on the 2600's drawing limitations, not on its ability to compute and store the information needed to draw it.

 

I think the information storage restrictions are going to be a huge limiting factor though. For one, you have to figure that you're going to need around 100 bytes as the playfield 'video RAM' to render the scene to, and that would just be for a 32x25 (or 40x20) pixel monochrome scene.

 

I suppose some kind of engine that utilized the ball/missile graphics to draw grid lines might be possible, but i think that's beyond my ability to even think about at this point...

 

Ben

Edited January 18, 2008 by Ben_Larson

[+grafixbmp]

on a side note, several people always talk about not using flicker if at all possible. I (many times) suggest using 30Hz flicker for many things but others try to refrain from this. Well, if that is the case, how come in the old game Night Driver, I NEVER could tell that it was using 30Hz flicker to display the road and other obsticals one frame and your car thingy the other frame. It seems to me that 30Hz is very acceptable in any case. Now granted, it may depend on the colors you are using during a 30Hz flicker to get more on the screen, but on the other side of the coin, I agree that pac-man wasn't the best game when using 15Hz flicker for ghost. I haven't ever hooked an atari up to an LCD or plasma screen so I don't know if flicker looks worse or not on thoes type of TV's.

 

edit:

Also, now that I think about it, I had also been working on figuring out how to do a traditional wall based 3d without turning the screen vertical. Maybe a type of horizontal ray casting instead of the traditional vertical strip version. This way you only have to go as far as the horizon and then just mirror what you did for the top part.

 

Here is a mock up I did for a doom style layout. the top part is the screen and the botom is a simplified/redesigned map of the first level of DOOM just to get a feel for the game design. I also re did it without any altitude changes. one strait flat playing field.

 

Doom_2600.bmp

Edited January 18, 2008 by grafixbmp

[supercat]

Well, if that is the case, how come in the old game Night Driver, I NEVER could tell that it was using 30Hz flicker to display the road and other obsticals one frame and your car thingy the other frame.

 

Probably because of the black background. Seriously. Flickering objects in front of anything that isn't black will appear transparent. Flickering objects on a black background don't have that problem.

[potatohead]

Hmmm...

 

Always noted this --even as a little kid. At that time, I thought it was done for effect!

[+grafixbmp]

Well, if that is the case, how come in the old game Night Driver, I NEVER could tell that it was using 30Hz flicker to display the road and other obsticals one frame and your car thingy the other frame.

 

Probably because of the black background. Seriously. Flickering objects in front of anything that isn't black will appear transparent. Flickering objects on a black background don't have that problem.

 

What about using a color compensation table? Lets say you have a bright BG color and a darker BG pixel. Then when you have a darker BG color, you use a lighter BG pixel color. basicaly oppose the colors.

If you had say blue bands going from the top down and get lighter as they go, overlay a 30Hz flickered pixel band that goes from lightest to darkest in say brown. The brown would be lighter at the top and darker at the lower side while the blue would be darker at the top and lighter at the lower side. Then you could have the other 30Hz be yellow which would display lighter at the top and darker at the bottom. This may help with consistency but when the yellow would be displayed over blue, it would look green and I have no idea what brown would be over blue. I am only thinking of this in conjuction with my edited post above and the pic file in it.

 

Not sure if it would look like this or not but this is what I am getting at :

 

atari_2600_color_compensation.bmp

Edited January 18, 2008 by grafixbmp

[SeaGtGruff]

when the yellow would be displayed over blue, it would look green and I have no idea what brown would be over blue.

Depending on the exact hues and luminances of yellow and blue, the mixture might look like light green, or it might look grayish (because blue and yellow are opposites as far as RGB values go, and mixing opposite colors will generally give you a grayish result). Mixing brown and blue can give a dark green-- think of brown as dark yellow, so if mixing yellow and blue gives light green, then mixing dark yellow and blue gives dark green. But you generally need to tinker with the hues and luminances to find the best blends.

 

Michael

[Ben_Larson]

K, I read up on raycasting engines, and I think maybe I have an idea for such an engine that doesn't really use any multiplication or division other than power of 2 multiplication / division. The idea goes like this:

 

First, have an 90-entry trig lookup table in ROM. Each entry would be 16-bits and represent the X component of a unit vector from 0-90 degrees. To get the Y component, one would just look up 90 degrees minus the current angle. This is pretty much what I do in my game 'Incoming!' to calculate shot velocity unit vectors. Computing the unit vector for all 360 degrees would just be a matter of multiplying one or both vectors by -1 depending on which of the 4 90-degree quadrants you're currently in.

 

Now have the playfield as a 256x256 bit grid. Player position is a 16-bit number representing integer + decimal part.

 

Now lets say we're using a 30x25 playfield for the screen. For a given position and viewing direction, you'd then need to cast 30 different rays corresponding to the 30 columns of the playfield. You presumably have the player's current facing angle, so you look up each unit vector one at a time for player angle - 15 through player angle + 14 via the trig lookup table.

 

For each unit vector, you start with the player's current position and keep adding unit vectors till you run into a wall (and keeping track of how many unit vector additions you've done so far for that angle). Then after you've hit a wall, you could use geometric addition subtraction until you zero in on exactly where the wall boundary is, i.e. subtract half a unit vector, see if you're still inside a wall, if not add, 1/4th of a unit vector, see if you're outside the wall, etc. In this way you can find out exactly how far the player is to the wall along that angle.

 

Then you just have a routine which computes how tall the wall should be at that column for a given distance. This could be as simple as a lookup table since our vertical resolution is only 25 pixels, i.e. the wall has to be either 1, 3, 5, 7, 9, 11, 13, 15, 17, 19, 21, 23, or 25 pixels high.

 

This doesn't take into account distortion correction, but other than that I think it should work. Maybe I've forgotten something, though, I dunno. Tell me what you think...

 

Ben

Edited January 18, 2008 by Ben_Larson

[Ben_Larson]

sorry accidentally posted twice...deleting!

Edited January 18, 2008 by Ben_Larson

[+grafixbmp]

sorry accidentally posted twice...deleting!

Did you see the pic I have above of a Doom style layout I was just trying to get a feel for the look of doom. Not anything that would look exactly like that on a real atari. But I would like to know what you think. I like the whole ray casting thing, BUT! and this is a BIG but. NOONE should have to turn their screen sideways to play. period.

 

That being the case, the challenge maybe in doing this thing a piece at a time for 40 collums. OK... and GO! or BREAK! or whatever