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

[+grafixbmp]

Unfortunately, I don't have all the great tools at my hands so I have been doing the data by hand and it isn't pretty. I am afraid by doing it this way I will miss something. Anyone have any tools for transfering BMP images to byte size data for ICC?

I wonder if you could use the program mentioned here:

 

http://www.atariage.com/forums/index.php?s...t&p=1491393

 

Ya know, I had thought about that. However, the data needs to be broken up and resorted in such a way that I would need the 3 RGB images split up by 6 collums each as well as the 2 last pixels at the end and interleaved a line at a time from each of the 3 images and then the data needs to be fliped verticaly as well for use in a table so that it can be indexed. I had been doing it by hand and that is fine but I was converting the bianary (the pixels directly from the screen) to decimal visualy with the scientific calculator. If I did use an image to ASCII converter, I would then need to change the characters to 0's and 1's and then would need to run the list through a bianary to decimal converter.

But I may try that out anyway. Shure couldn't hurt. I have done most of the arangement to the images anyway hence the GIFs.

 

Incedently, That post you mentioned was started by me and was originaly about using BASIC draw for graphics which is exactly what I used to get the separate RGB valued images I needed. I just slightly modified the dither filter. Unfortunately, the software still has some bugs and issues with saving that I circumvented by just hitting print screen.

 

Quote from MousGames

The only problem I see with this is, you have to account for worst case scenarios, the engine has to still perform properly when the most is going on that can. What if the player is moving constantly forward and left, in a circle? Then sprite movement and scaling, and playfield rotation and scaling are all happening at once. I don't' really know what I'm talking about so please disregard if this is stupid.

 

I know what you are geting at and if that turns out to be a problem, I had thought about doing one at a time per frame First: forward, Second:left, Third: Forward, Fourth: left... just alternating between the movement one at a time

 

This would probably be a bit jerkey, but this, if need be, would be a small price to pay. It would slowdown apparent movement for sure but would allow it to work within a 5 frame gap for a refresh of the image. This wouldn't even be possible at this magnitude if it wern't for the extra RAM. I kinda wish Mindbleach would join back in. I miss his input. Unless he is working on something along the lines of this engine and will be back when he has a breaking point. He may surprise us yet.

 

On a side note. Here are the attributes of solid wall points. I will add more later but for now. There are 5 bytes for these.

 

 

1# Type of point (first byte)

2# X coordinate (second byte)

3# Y coordinate (third byte)

4# Angle away from open space (fourth byte)

5# entity's group (fifth byte)

 

The first is the kind of point you are addresing ie: wall, door, movable wall, etc

The second and thrid are the grid coordinates on a 0 to 255 by 0 to 255 grid

the fourth indicates a center angle which points away fromopen space which will indicate which side your player can be on.

And the fifth groups points into solid entities. This way we know what points belong to pillars and wat points flow along a wall.

 

In other sections of the data for the levels, there are other types of points which may have less bytes for their attributes. The solid entity data should be the most data for ANY point that the engine uses.

 

All entity group data is broken by standing objects and sector data.

 

In order to trace along a wall only with corner points, some rules come into play. First off. once a point is in memory, the next closest point is checked to see which axis it is closest to . A point may be 5 away from one axis and on the same row while anither point may be 20 way and on the same colum. In order to find which one you go to next, you check their angles away from open space and wrap the wall evenly around the point with the angles being the midpoints on the back side. Then check the next closest point from the point you just met.

 

In order to keep each point going to the correct points near them, you check to see what entity group they are in. If you have 4 points near each other but their group # doesn't belong to any other group, then they join each other and the angles away from open space directs the orientation of the wall wraping. If all 4 points are closest to you, then their rendering gets screen priority over anything rendered behind them. If any wall wrapings obscure any points, then thoes points are not processed. I hope this makes sence to all. These will be the rules for creating the 3D graphics from a 2D grid. And I hope I covered all the bases.

 

The nice thing about this is that when all teh data is compiles for the 3D aras, then the first thing you wind up with is a random grouping of collums at difrent heights on the screen and then slopes are generated between the collums that fit together. Like for every 2 pixels over you go 4 down or for every 3 down you go you 1 over untill you hit the top of the next collum. this process is duplicated in reverse for the bottom of the collums and filled in between them to produce a wall.

 

The real trick comes when you have created a single image and have that data in menory which was used to create the image altered based upon your point of view's movement with special calculations geared tward the slopes of movement that the walls will move in and just raw calculate with the original point casting process to plot new points that come into view or are needed to continue a wall past the screen.

Edited May 27, 2008 by grafixbmp

[+grafixbmp]

Not sure how possible this will be but I tried to fit it within ever parameter I know. This is the HUD for doom 2600 and is shoving alot into these limitations. First off both missles are used, preset to particular locations, are double width, and never move until the second phase of the HUD is started. This section also uses both sprites at tripples wide stance. And PF1 register on the TIA is used as well, I hope. Anyway, here's how it goes.

 

Missle 0 is used for a '1' digit of the ammo value. THe first full byte of the playfield is used for the other 2 digits of the ammo. This creates a space where uptoo 199 pieces of ammo (max) can be displayed for which ever weapon you have. The next spot has sprite 0 and 1 trippled with wide spacing and set one right after the other so you wind up with

 

XXOOXXOOXX

 

The first 2 have 3 digits in it. for a max upto 299 for health

THe next 2 have the image of your player as waht their current state is

The last 2 display your armor upto 299 possibly 300 not sure if I want to go that far yet graphicaly.

 

And the last part is missle 1 which is in place to create upto 3 color coded key icons

 

Under all of this is phase 2 of the HUD which simply, in 1 color produces a space with player sprites alone capable upto 24 characters of text. However, it is only used to display perminantly the words AMMO HEALTH and ARMOR

 

In the original, ARMS was also there but due to lack of room and there being no real need for it,It will be gone as well as other stats.

 

At the top of the screen is a message bar that can display upto 24 characters.

 

Here is an image of a mock of the HUD. And BTW, the sprites at the bottom for the first phase are in Interleaved chronocolour however, only the middle secton and the missle at end use it to its fullest potential.

 

[supercat]

Not sure how possible this will be but I tried to fit it within ever parameter I know.

 

Figure that you can write about 10 registers per scan line. Writing a register with a constant value counts about 3/4; if more than one register is written with the same thing, later writes count half.

 

Not everything that fits within that set of rules will work on the 2600, and not everything that goes beyond will be impossible, but I'd suggest it as a starting guideline.

[+batari]

Not sure how possible this will be but I tried to fit it within ever parameter I know.

 

Figure that you can write about 10 registers per scan line. Writing a register with a constant value counts about 3/4; if more than one register is written with the same thing, later writes count half.

 

Not everything that fits within that set of rules will work on the 2600, and not everything that goes beyond will be impossible, but I'd suggest it as a starting guideline.

Technically, if you had enough RAM, you could use immediate loads and self-modifying code and get 15 per line. Doing 192 scanlines will require nearly 12k of code, so you'd need some carefully-placed bankswitching and a jump at least twice in the middle of the kernel. That is of course neglecting the significant overhead required to update that code in vblank and overscan. You'd almost need a coprocessor for that

[+grafixbmp]

Lets see, First off during the first phase, there are 4 unused scanlines where everything is HMOVEd to their places and the players are set as tripple wide with the 2 missles set at their locations being double width. During the scanlines (first phase is 14 scanlines with 4 leading in and 4 trailing before the second phase, the playfield 1 is set with data stored in RAM and missle 0 is either all on or all off for the entire span. The second missle can also be set and is either set for first four scanlines without the fifth line on. the next 4 starting with the sixth without the tenth on and/or the eleventh to the 14th turned on. The playfield register needs to be turned off before it gets displayed and one way that could help for this area of the screen could be to mirror the right hand side (hope this would work to buy time since that places it more to the right than nonmirrored. Then the sprites can be preloaded for the first part of their data. and the vertical delay could be used for the next one. Since there is a gap of about 5 clock cycles before the next ones are displayed with 3 more before the second player 1 is got to, that should be ampleroom for the 4 piece in the sequence.Turning off the playffield 1 piece then loading the last 2 sprites in time without the playfield displaying on the right side. Not toe mention all sprites will ned to change color values every single scanline.

 

For the next 4 blank scanlines, the playewr sprites are HMOVEd again and set for 24 character display where this will NEVER change during the game. This will display AMMO HEALTH and ARMOR. I sure hope I can come up with a single display of this. This area could use a mini kernel that displayes updates evert 3 frames so to be in sync with the chronocolour. Incidently, the numerical values for each of the 3 frames will be only displayed ever third scanline and blanked the rest.

 

The first missle could be turned on or off before the first scanline even starts. and the sprites for the first part can be done at the tail end of the previous scanline followed by PF1 and missle 1. Then the colors can be changed before missle 0 is displayed. I need to work this out on paper.

 

 

The mian gameplay area is schedualed to be updated every 5 regular frames. The HUD is arbatrary. It just has to be updatable period and doesn't neccesarily have to be 14 scanlines deep which is the hardest portion of the entire HUD. The labels at the very bottom are static so that can be exact code everytime.Sectionsd where no data will be displayed inthe chronocolor area but red can be instantly blanked with the fastest load and store.

Edited May 30, 2008 by grafixbmp

[+grafixbmp]

It has been a while since I have been able to get back to this. I have a big move coming in a few weeks and I got a job promtion about a month ago which I am still geting settled into. I hope to be back at it ina few months more regularly.

 

But in the mean time I have came to realize that one of the biggest benifets to having extra RAM is that you can create dynamic code in the sence that many parts of the whole can be generated to be specific to current elements in the game and then executed at the right time in sequence.

 

Also depending on if the results are worth it or not it could be better to do 6 frames at a time instead of 5. In cases where a door or new room is coming up, there could be the chance of using a few extra frames to gain all the needed data from the new room thereby keeping each room running smoothly and not so much between transitions.

 

With plenty of extra ROM and a considerable space of RAM, it should just be a matter of designing a vast set of equations and self modifying code that fully utilizes the binefits of extra ROM and RAM to push the haardware specificaly the TIA to the limits. And since there are several extra frames which do no visual changes to the screen except for multiplexing the sprites, there should be enough time to regenerate the screen before it is to be displayed.

 

The beauty of all of it is that there is no REAL texturing involved. Just sudo insinuations of things in the 3D locations just by following a few rules and adding strait masks to certain parts of the screen and also to the sprites as well. Ass long as the implication of recognizable atributes of 3D objects exist, than the effect is acheived.

 

The way EVERYTHING is viewd adhires to a specific set of rules that never changes so and if these rules are the boundary than as long as the boundaries are never met, then things should run smootly.

 

No need to test fore things that we know not to exist. That statement already saves us from unnecesary work.

[Gip-Gip]

I see I am about 6 years late, but if any of the users who are on this topic are still active, I think if we are to get the best amount of frames per second we should probably make the HUD as minimal as possible. like just a cross-hair in the middle of the screen that shrinks as your health goes down. Also we should try to avoid floors with different heights and textures(or colors). But other than that, it looks good!