As soon as the ROM has as many features (and maybe more, such as a HUD and collision detection) as the Flash prototype, I'll release it here.

I'd also like to use this opportunity to ask of you guys if you'd like to see this turned into an actual game in case adding objects and enemies works out well (i.e. it doesn't get slow like shit). If you want to, please tell me if you'd like to play a game using this engine and why / why not. Thanks.

You may have noticed that the framerate dropped a little (15fps to 12 fps). That's because I needed one extra VBlank in order to update the palette and the attribute tables. But since there currently is a lot of waiting for VBlank (I'm wasting a total of nearly 300 scanlines), by reorganizing the rendering pipeline to be more efficient I can probably win that frame back. I believe that the final product will alternate between 15 and 12fps, so the experience shouldn't be too bad.

Next I'll implement the different textures, and after that I'll probably enable walking and then it might be the time to post a ROM! =)

It looks pretty similar to the Flash prototype now. There just a couple more things I want to do before releasing a ROM.

UPDATE (nov 17 2009):

Grab the first public ROM here. There is still a lot to do (the walls aren't even solid yet), but not having time to advance with the project is not an excuse to just sit on the ROM, since the goal was to prove that a raycaster with these specifications could be done. So if you must see to believe or just want to play a bit with it, grab your copy!

UPDATE (may 24 2010):

Second public release here. Walls are now solid. That's probably the only significant change.

Last edited by tokumaru on Mon May 24, 2010 3:02 pm, edited 6 times in total.

I never liked 3D shooters much (although I followed the genre from the start, I had Wolfenstein 3D on my brand new 386), but the other day I ended up playing around 5 levels of Doom on the 32X and I kinda liked it.

Games with rooms where you can walk freely are certainly much better than the sad excuses for 3D that 8-bit corridor games were. My doubt is whether the NES can run a 3D engine that's still fun enough to play, as opposed to being so blocky and slow that it can't even be entertaining. I guess it would still make an interesting novelty...

I don't usually think in terms of what a platform normally represents, in fact I get a real kick out of seeing them do something they weren't meant to! =)

I just found out that the dithering patterns I selected suck when encoded to NTSC. Can anyone suggest better patterns? I need 4: light pixel of light wall (this should be the plain color with no dithering), dark pixel of light wall, light pixel of dark wall, dark pixel of dark wall. The "pixels" are made of 8x2 hardware pixels.

Tokumaru, very cool. Are you displaying your graphics in a 128x128 pixel square so you can basically use all the available chr-ram tiles as a "framebuffer?" Seems like it would be rather challenging to do it full screen, unless you had some crazy scheme of figuring out what pattern of tiles would create different angled lines that can repeat all the way across a wall...that'd be nuts =) probably doable though...

*edit* it also occurred to me that attributes must be a real problem with this engine, you probably would just have to be restricted to 4 colors at a time?

I have been fascinated with raycasters for a while...I've written a few for the PC so I'm rather impressed seeing one work on the NES!

Are you displaying your graphics in a 128x128 pixel square so you can basically use all the available chr-ram tiles as a "framebuffer?"

No... A long time ago I decided that updating the patterns themselves would take too much time, so I designed a system with a few restrictions that would make it possible to store all possible pixel combinations in less than 256 tiles (178 to be exact, so there are quite a few left for an interface around the 3D view). The 3D view itself is 224x128 pixels large (28x16 tiles), so it's larger than it would have been possible with 256 unique tiles.

In this post you can see the tileset used to draw everything. I just got rid of the top 4 rows because the they were redundant (the next 4 rows have all the tiles, only in a different order) so I gained 64 tiles. Also, the pure ceiling and pure floor tiles are missing on that image. In the current program these are tiles #240 and #241, but they could be anywhere else.

Quote:

Seems like it would be rather challenging to do it full screen

It is, but not really for the reasons you mentioned, since I'm not rewriting the patterns. Texturing would be much slower, because the current height is as far as I can go and keep the texturing math 8-bit. If it was extended to 16-bit it would probably be more than twice as slow. Increasing the views to the side would mean casting more rays, so it would of course take longer to render a frame, not to mention that a larger area of the name table would have to be updated. I find the current size to be the best compromise.

Quote:

it also occurred to me that attributes must be a real problem with this engine

It is, since the walls can have different colors, it is a problem when they meet outside of an attribute boundary. To handle that I had to dedicate 3 palettes to the 3D view, each with a combination of 2 possible colors meeting. As a result, a view can only show 3 different hues. So each view can show the following colors:

If a fourth color is found, it will be displayed as if it was the third, so the rooms must be designed in a way that no more than 3 colors show up in the same view. If an MMC5 was used an attributes weren't a problem, up to 6 wall colors would be possible in the same view.

Quote:

you probably would just have to be restricted to 4 colors at a time?

Like I said above, 3 actual wall colors are possible, each dithered with black to form different shades. The YouTube video shows only 1 wall color, purple, but I'm working to change that real soon.

Quote:

I have been fascinated with raycasters for a while...I've written a few for the PC so I'm rather impressed seeing one work on the NES!

Same here. I made a bunch in QBasic and Delphi, and always liked to see them working on various platforms, so it was kind of a dream of mine to see the NES running the best one it could. Not that I'm saying mine is the best possible... In fact, being a raycaster fan I'd love for someone to make one better than mine! =)

PS: Looking at that old thread I think it's funny that I was able to implement most of the ideas I had back then unchanged, even though it took me more than 2 years to actually start coding this! If only there was an easier way to make our ideas become reality rather than actual work...! =)

Looks promising. You do it with the 256-tiles technique, using 8x2 "textels" right ?

Only 178 are needed for the 3D view. The rest can be used for a border/interface/HUD. But yeah, software pixels are 8x2 hardware pixels.

Super-Hampster wrote:

Does it work on real hardware?

I don't know. I have ignored some basic initialization steps (clearing the name tables and things like that) because I was in a hurry for results. But I have cleaned things up a lot since, and maybe it's time to test on hardware. I'll try on my PowerPak and let you know.

Are you talking about the Flash prototype where you can walk through walls? If so, yeah, on the NES they will be solid, it's just that moving the player around and colliding with walls is a trivial process that I'm not worried about for now. Once rendering is 100% that can be added pretty quickly.

I'm now reordering the rendering process to see if I can increase the framerate a bit. I'll soon look into movement and collision! =)

Who is online

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum