Hello everyone. From now on, this is where I'll place news regarding my raycasting engine for the NES. In case you haven't heard about it, here are some of it's features:
. 8x16 pixels 1-bit wall textures;
. Up to 3 different wall colors per room (shades achieved through dithering);
. Map sizes up to 128x128 blocks (AFAIK, Wolf3D levels were 64x64);
Planned features are:
. Doors that open and close (as opposed to teleporting walls);
. Enemies and objects decorating levels;
. Music and sound effects (will need some help here);
Here is the flash prototype:
http://www.nesstuff.kit.net/raynes.swf
Here is a video of the first ROM that displays something meaningful:
http://www.youtube.com/watch?v=kTmlBnbvP2o
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.
UPDATE:
New video, showing walls of different colors:
http://www.youtube.com/watch?v=aHVJO1MdFbM
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! =)
UPDATE:
Tested on a real NES. Results here:
http://www.youtube.com/watch?v=pkAao7OtqSk
It works fine. There is just some name table garbage at the top because I didn't clear the parts I'm not using.
UPDATE:
New video:
http://www.youtube.com/watch?v=po69zgqyFWM
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.
It's good to at last see some results about your ray caster, good job
About a game, personally my answer would be no: for me the nes represent 2d platformers and the like. I always hated the 3d corridor type game so a ray caster would fall for me in the same category.
It doesn't mean that I wouldn't try your game since I would still like to see the technical aspect of it but the game itself wouldn't keep my interest very long.
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!
Zero wrote:
Tokumaru, very cool.
Thanks!
Quote:
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:
.Ceiling/floor: currently gray, can be changed for each level;
.Dithering color: black, could be changed but I don't see why;
.Wall color 1 (first color found);
.Wall color 2 (second color found);
.Wall color 3; (third color found);
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...! =)
Very cool. And yes, I would like to see this as a game.
Nicest looking raycaster I've seen on the NES so far.
Looks very nice. It would make an excellent game, especially if it resembled 3D Zelda-style labyrinths. This engine has a lot of potential.
Thanks for the comments guys. The first post has been updated with a new video!
Looks promising. You do it with the 256-tiles technique, using 8x2 "textels" right ?
Does it work on real hardware?
Bregalad wrote:
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.
Best raycaster on the NES if you make the walls solid.
CKY-2K/Clay Man wrote:
Best raycaster on the NES if you make the walls solid.
What else would they be? =)
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! =)
Super-Hampster wrote:
Does it work on real hardware?
Just tested. See link in the first post.
It looks cool. I'm looking forward to seeing the new textures and the movement.
Well congratulations what else can I say ? It really looks decent to say it runs on a NES ! Altough I've always preferred 2D games, it's really exciting to see a (pesudo) 3d engine working on the system that wasn't designed for that. It already looks way better than 3D worldrunner, slalom and stuff like that.
That's awesome.
I love how your NES has no top too. lol
Memblers wrote:
I'm looking forward to seeing the new textures and the movement.
Since the resolution is so low, textures will only look good when you can actually move around, so that if you can't see a texture well you can get closer to it or look at it from different angles.
I plan to keep the textures pretty simple. Like I said, their size is 8x16 pixels, but as you can see in the videos, the faces of some blocks end up taking only 2 columns of the screen, so there is no way they'll look awesome there, it's impossible to scale 8 to 2 and keep any detail.
Well, you've probably seen the textures in the Flash demo, it will be exactly like that. The key is to design textures with little horizontal detail, and focus more on vertical detail.
It is awesome!
Ofcourse it'll probably never make a good game since the platform is too limited. but that's not really the point here.
Great work!
New video! Check the first post.
Can anyone suggest a good place to host the ROM (somewhere I don't have to register and won't expire anytime soon)? I might wanna do it soon, even though there's still a lot to do.
tokumaru wrote:
UPDATE:
New video:
http://www.youtube.com/watch?v=po69zgqyFWMIt looks pretty similar to the Flash prototype now. There just a couple more things I want to do before releasing a ROM.
Very cool.
Keep up the good work.
Great but the ground looks horrible in revision 3, in my opinion you should revert it on how it looks in version 2 (if that's technically possible).
Other than that great work can't wait to have the ROM released.
Great job, tokumaru! This raycasting is actually bearable to look at (pretty damn impressive, as a matter of fact), and I would probably enjoy myself if I were playing a game with these graphics. This is pretty hard to do with raycasting on the NES
.
Anyways, I do have to agree with Bregalad to some extend about the ground. The dithered pattern looks a little big, and it makes it seem like the ground does not extend into the distance. If you undithered the ground pattern, this wouldn't be the case. Otherwise, the walls look great, it runs smoothly, and I can't wait to see more! I hope you make a cool game out of this or something
.
EDIT: I just had a question about the colors. It seems like you have more than 4 colors present for these walls and the ground. I'm assuming the entire image is part of the BG, so I'm wondering if you are working with color attributes in this project? If so, that's very impressive! That must be a nightmare to do. If not, well it's still impressive because it seems to me like there are more than 4 colors visible.
tokumaru wrote:
Can anyone suggest a good place to host the ROM (somewhere I don't have to register and won't expire anytime soon)? I might wanna do it soon, even though there's still a lot to do.
Sorry about the double post, but yes, I could have the ROM up on my site. Well, I wouldn't have info about it, but you could download it from
www.freewebs.com/the_bott/tokumarusROM.NES or something like that if that's what you were wanting.
Before this, I wouldn't have expected an raycaster on NES to look that good. Pretty nifty to watch the textures kinda fade in as you walk towards the distant ones.
tokumaru wrote:
Can anyone suggest a good place to host the ROM (somewhere I don't have to register and won't expire anytime soon)? I might wanna do it soon, even though there's still a lot to do.
I can give you an FTP account on the membler-industries server. Just PM me the username/password you want.
Bregalad wrote:
Great but the ground looks horrible in revision 3, in my opinion you should revert it on how it looks in version 2 (if that's technically possible).
The routine that generates the patterns accepts the floor and ceiling patterns as parameters, and the dithering patterns of the walls are in a table, so all of them are easy to change.
But I'll tell you, finding patterns that look good in NTSC is pretty hard! But I'll give it a try. I'm not happy with the floor or the dark pixels of light walls.
Celius wrote:
Great job, tokumaru! This raycasting is actually bearable to look at (pretty damn impressive, as a matter of fact), and I would probably enjoy myself if I were playing a game with these graphics.
It's great that you think like that! IMO, it doesn't look so good in fullscreen, but that's when I'm close to the monitor. Since we usually sit quite far from the TV, it should be OK.
Celius wrote:
I just had a question about the colors. It seems like you have more than 4 colors present for these walls and the ground. I'm assuming the entire image is part of the BG, so I'm wondering if you are working with color attributes in this project?
You are correct, there are more than 4 colors. There are 5!
1 = floor/ceiling;
2 = dithering (black);
3 = wall color 1;
4 = wall color 2;
5 = wall color 3;
It may not sound like a big deal, but I believe that you'll agree that 3 wall colors in one scene is much better than 2. And yes, that adds significant complexity. The colors might have to share an attribute column with another color, and for all possibilities I have to select the correct palette and use the correct patterns while rendering. A table helps me with this.
You'll understand when you use the PPU viewer in FCEUXD. Watching the palettes changing as different walls are found is pretty cool. This happens because even though only 3 walls can share the same scene, these colors are dynamic, so you can have as many as you want in a level, as long as no more than 3 of them meet in the same view.
Thanks for the hosting offers, I guess it make sense to take Memblers' offer, since we were thinking of including a version of the raycaster in his garage cart.
Hey tokumaru, I think this is excellent! Very nice work. As for game ideas, it could be as simple as a maze, trying to find the exit within a time limit. How much wiggle room do you have for enemy sprites/gameplay ?
3d pacman type game could work, but with mario and collecting coins instead of pellets. Maybe have goombas chasing u. Instead of the big power pellet, have the stars that makes him invincible and allows him to kill them by touch. Maybe put in power ups scattered through out the maze like the flower that allows him 2 shoot fire balls.
Well tokumaru, if you can't host it why don't you ask Memblers to host in on the main nesdev page ? Pretty much a lot of old demos are hosted here, I don't see why your new demo wouldn't.
And if you can't make a full game with that it really doesn't matter ! You still did a really great prime demo, and proofed something new possible on the NES ! Like when I did my pseudo mode-7 demo, I didn't make a game out of it but I still enjoyed programming it and seeing the results.
And if you want to continue progress and make a game out of this, it shouldn't be TOO hard to make sprites with different sizes like in 3D-Wolrdunner, it just eats you a great amount of tiles for each sprite that way, but you can adjust the amount of diferent size in function of how much free-space you have.
One problem is that a first-person view needs really BIG sprites if there are other creatures in the room who are reasonably close to the player. Another is occlusion; how can a sprite be half in front of and half behind a wall?
Quote:
Another is occlusion; how can a sprite be half in front of and half behind a wall?
Yeah it seems like a problem but seeing how gross the resolution is horizontally, a 8-pixel error will be OK. Altough computing the on/off state for each state will eat CPU time.
Quote:
One problem is that a first-person view needs really BIG sprites if there are other creatures in the room who are reasonably close to the player.
Well you can limit the size of enemies, or do a 3rd person game like 3D WorldRunner.
Can the object be part of the background instead of a sprite?
RetroRalph wrote:
As for game ideas, it could be as simple as a maze, trying to find the exit within a time limit.
Yeah, this is the simplest game possible, and could be done with what is already working.
RetroRalph wrote:
How much wiggle room do you have for enemy sprites/gameplay ?
I really want to add objects to that engine, but the calculations are very different (and more complex) than what's done for the walls, but I do want to say that it should be possible to have 2 or 3 active objects and still have playable speed.
Luckily, the game logic is much simpler than in a platformer, for example. There's no physics only simple collision detection. The AI for the enemies could be very basic as well, so I doubt that would take much of the processing time.
HJRodrigo wrote:
3d pacman type game could work
You had a very interesting idea, but I guess that being chased without being able to see your back could be frustrating. Unless there was a map active at all times, but then it would be like regular Pac-Man, but slower and with a gimmicky 3D window at the top. So I guess this idea needs some adjustments, but yeah, it's interesting.
Bregalad wrote:
Well tokumaru, if you can't host it why don't you ask Memblers to host in on the main nesdev page ?
Hosting is solved, Memblers got me an account (BTW, thanks Memblers!). Some time this week I'll probably upload something.
Bregalad wrote:
And if you can't make a full game with that it really doesn't matter ! You still did a really great prime demo, and proofed something new possible on the NES ! Like when I did my pseudo mode-7 demo, I didn't make a game out of it but I still enjoyed programming it and seeing the results.
Yeah, I'm already glad it's possible to walk around! I believe I will try to implement objects though, even if not right now.
tepples wrote:
One problem is that a first-person view needs really BIG sprites if there are other creatures in the room who are reasonably close to the player.
The static objects could be carefully designed to be really thin, or too short to be visible from so close. Being attached to the floor or the ceiling you wouldn't be able to see them because it's not possible to look up or down. Enemies could detect when the player is too close and move away by themselves. In the end it might be fun to play "chase the enemies"! =)
tepples wrote:
Another is occlusion; how can a sprite be half in front of and half behind a wall?
NES sprites are 8-pixels wide, the same as the columns in the background. If the objects are aligned with the walls it would just be a matter of comparing the distance of the object to the distance of each background column and not rendering sprites for columns that are more distant than the wall they'd otherwise cover.
Bregalad wrote:
a 8-pixel error will be OK.
Or that. I'll have to try when the time comes.
CKY-2K/Clay Man wrote:
Can the object be part of the background instead of a sprite?
Not in this engine. The possibilities for background patterns have been carefully calculated to allow the 1-bit textures, the light/dark separation and the multiple wall colors and still leave some free tiles (for a status bar and some decoration). Including foreground objects in the mix would mess everything up. Plus, there would be very few colors.
I'd rather use sprites for them. It will add some extra colors to the screen, and I think it really needs it. Also, if I take the bitmap route, I plan on giving the objects twice the horizontal resolution of the walls (software pixels will be 4 hardware pixels wide), hopefully making the whole thing look a little less blocky.
Perhaps it would be possible to make a game where you are fighting gnomes or something really small so you'd have an excuse for small enemies, haha. You should make a game based off an idea I had when I was thinking of making a NES raycaster. The plot of the game was that you were a wizard who was sucked into another dimension, and your only defense was your wand, with which you could cast rays at enemies. The game was going to be called "Ray Caster" for this reason (and also, because it's a raycaster. I'm sure you get the joke!). But if that's too corny for you, I don't blame you!
But if you're going to be using big enemies, I would probably stick with 8x16 sprites, obviously because you can make larger enemies out of sprites with that. However, you're still stuck with 8 sprites per scanline. Didn't we have this discussion somewhere else?
Anyways, I can't wait to see more! I really hope you do something cool with this (though it's already really cool by itself, it would be really cool to see a game out of this).
EDIT:
tokumaru wrote:
Luckily, the game logic is much simpler than in a platformer, for example. There's no physics only simple collision detection. The AI for the enemies could be very basic as well, so I doubt that would take much of the processing time.
Well, try imagining making a top-down maze game where you and the enemies are represented by dots and the rest is just an ugly set of "floor" or "wall" squares. Then you and the enemies try and kill each other. All of the objects can spin 360 degrees and face any direction. Whichever direction they are facing, that's the direction they can attack in. That sounds very easy to code, and that would be pretty much the same game logic in a raycaster, just the rendering would be 3D rather than 2D.
Quote:
The plot of the game was that you were a wizard who was sucked into another dimension, and your only defense was your want, with which you could cast rays at enemies. The game was going to be called "Ray Caster" for this reason (and also, because it's a raycaster. I'm sure you get the joke!). But if that's too corny for you, I don't blame you!
My this is a cool idea. You can be sure the average gamer don't notice this subtle joke.
I can't wait to see the ROM, I can't wait to see the ROM, I can't.....
Oops, I meant "wand", not "want" in the post above. You have a wand that you cast rays at enemies with. But yeah, lots of people wouldn't get the joke, but I'm sure a lot of people would get it too.
Your defense may be your want, but then you'd have to fight against the DO NOT WANT dog! (Or Anakin Skywalker)
tokumaru wrote:
You had a very interesting idea, but I guess that being chased without being able to see your back could be frustrating. Unless there was a map active at all times, but then it would be like regular Pac-Man, but slower and with a gimmicky 3D window at the top. So I guess this idea needs some adjustments, but yeah, it's interesting.
I guess a red alert can flash or sound when you have an enemy in close proximity behind you. Kind of like how Flight sim games do when an enemy behind you has locked on to you.
One idea you could try is the one Roth had: a 3D maze light gun shooter. One hand the controller for moving, the other hand the zapper. I don't know how much complexity it would had to it.
maybe if the controller was held sideways. That's not a terrible idea at all. It might be hard to open doors since you can't reach the buttons. You might have to shoot the doors open, that is if there are any doors.
@Banshaku, Super-Hampster
There is at least one controller + light gun game for the NES: Gotcha!, which is a paintball game where you move around with the controller and shoot with the Zapper. So yes it is possible.
Also, Tokumaru, have you considered doing a 3D glasses version (like what 3D World Runner and Rad Racer have)?
CartCollector wrote:
Also, Tokumaru, have you considered doing a 3D glasses version (like what 3D World Runner and Rad Racer have)?
I haven't, but this is an interesting idea. This should be simple to do mathematically, but there are some limitations that are likely to get in the way.
Since the frame rate is about 15 fps, in order to switch between two different views as fast as necessary I'd have to render one to each name table, and this means I loose my off screen buffer, unless I use 4-screen mirroring. Also, since two views are necessary for the 3D view, it will be twice as slow, which should be quite unplayable.
Another problem I see is that because of the low resolution, maybe not every column on the left view will have a right view counterpart, and this might compromise the 3D illusion.
Hello everyone. Sorry for the lack of updates on this, but real life demanded too much attention recently.
Just to keep you all interested, I decided to release a
ROM even though I wasn't able to advance much. Walls are still not solid (sorry CKY-2K/Clay Man) as it's not really a priority. Just try not to go outside of the map or it can glitch up pretty bad. I'll add collision for the next ROM, I promise.
Feel free to suggest stuff.
Well thanks for uploading, it's really impressive to see that on the NES, and it runs at a smooth rate, altough it's true it looks a bit blocky and I can't imagine myself playing a game with such graphics for hours.
From a technical point of view, it is impressive to see it could be done on the nes. Now how much extra can be added (music, game logic etc) will be interesting to see.
Like Bregalad, I don't have must interest about the possible game (like mentioned before I'm not a fan of 3d maze) but can't wait to see the outcome.
Continue the good work
Wow! Really impressive!
Thanks for uploading this; I was very curious to see this actually running on the NES. Not that I didn't believe it could; I just wanted to see the real, undeniable proof
.
I do agree to some extent that it's a bit blocky, but I would not go as far as saying I wouldn't be interested in a game release. I think it could be one of those games where you'd get used to the graphics after sitting through them a while. Though I guess it really depends on how the sprites look. If the sprites are pretty clear, then I stand by my statement. If the sprites are really blocky too, I might reconsider.
What I would do if I were making a game is probably simplify some of the textures. Any real "headache" that comes from walking around is caused by scaling complicated textures that aren't accurately displayed from far away. If you had stuff like the bricks on the red walls, and maybe not the more complicated textures on the yellow and purple ones, I think it would look better for a game.
But still, we are dealing with the NES. What you've done is very impressive. Look at Space Invaders, then look at your demo. Same system. Same capabilities. Even the same mapper, am I not mistaking (Well, absence of a mapper)? All around, great job. That would have taken me a million years to code, and I probably would have given up on it after a while.
You think it could have textures like 8-Bit Killer? Or would that be too much chr?
http://www.youtube.com/watch?v=Dwj_1Dngzio
Celius wrote:
I was very curious to see this actually running on the NES. Not that I didn't believe it could; I just wanted to see the real, undeniable proof
.
I get it. A video looks the same as a video made from the prototype, so it's not nearly as interesting as seeing it running on the real thing. Plus there are a lot of people who post fake things all around the web (remember Sonic 2 for the NES?), and before anyone thought I was one of them I decided to just release some proof.
Quote:
If the sprites are pretty clear, then I stand by my statement. If the sprites are really blocky too, I might reconsider.
The sprites will either be very blocky bitmaps or composed of simple common polygons (circles, squares and triangles of different colors) that can be pre-scaled. I'm still not sure what will work better.
Quote:
What I would do if I were making a game is probably simplify some of the textures. Any real "headache" that comes from walking around is caused by scaling complicated textures that aren't accurately displayed from far away. If you had stuff like the bricks on the red walls, and maybe not the more complicated textures on the yellow and purple ones, I think it would look better for a game.
I completely agree with you. The less horizontal detail the textures have, the better they look in the game. But I don't want them too look too dull either, because when you're really close to the wall you can see how blocky the textures themselves are.
Quote:
Look at Space Invaders, then look at your demo. Same system. Same capabilities. Even the same mapper, am I not mistaking (Well, absence of a mapper)?
I used mapper 2 because I plan on extending it into a real game and because I use CHR-RAM, but currently it would work in an NROM board just fine (I'm not updating the CHR-RAM in game or doing any bankswitching).
Thanks for the interest guys. Let's see how far I can go with this!
strat wrote:
You think it could have textures like 8-Bit Killer?
No way! =)
IMO, 8-Bit Killer was not meant to look like a low-tech 3D game, it's goal was to capture the overall look of 8-bit 2D games and apply that to a high resolution raycaster. Although the textures are very pixelated, the walls and objects are rendered with very good resolution.
I have only 28 columns of vertical resolution, and even that is a lot to ask of the CPU. For each column, 2 rays have to be traced (one looking for vertical walls and one looking for horizontal walls), and tracing those rays until they hit walls demands a lot from the CPU. With my current design, I can't possibly increase the horizontal resolution without killing the frame rate, even if there is a way to represent the better resolution with the tiles (which I don't think can be done with just 256 tiles anyway).
I'm sure something that looks better can be done, something that renders tiles in real-time and uses both pattern tables, one for the top and one for the bottom, with mapper IRQs to split the screen. I'm sure that would look much better than what I have, but I'm also pretty sure there would be a big performance hit.
Here's an idea: ever since I saw mic's raycaster, I always thought it'd be cool to use smooth horizontal scrolling via $2005 to make the movement less jerky when rotating your view.
The idea is that you fake the rotation by simply scrolling the view horizontally, for say 4 pixels, and only then render the new view, and scroll negatively for -4 pixels at the same time. How to translate your rotation angle will require some experimentation rather than orthodox correctness, but I think it could look really good despite being a crude hack.
If it works well you could even add some inertia to the player's movement, so that the angular velocity grows for a few frames when you start pressing left/right, and shrinks back to zero for a few frames when you release it.
Bananmos wrote:
Here's an idea: ever since I saw mic's raycaster, I always thought it'd be cool to use smooth horizontal scrolling via $2005 to make the movement less jerky when rotating your view.
This is a very interesting idea. A bit hard to implement though, because the 3D window doesn't use the whole horizontal area, so there'd be some left overs tiles visible at the sides unless they were covered with sprites. Using sprites to cover glitches while this is just a demo is OK, but once objects are added, using sprites for that will be a terrible waste.
Another problem is the status bar. Once it's added to the bottom of the screen, it can't be scrolled along with the 3D window, so an IRQ would be needed to create a split between the 3D window and the status bar. Not terribly difficult to do, but in order to be done without much waste of time a mapper with scanline IRQs would have to be used, and I'm avoiding them as much as I can.
Quote:
If it works well you could even add some inertia to the player's movement
Some inertia might be added even without the fine scroll. You see, I'm adding 2 units to the angles when turning, because 1 unit at 15 fps was too damn slow and frustrating. With inertia, the player would turn slightly slower at the start and at the end of the rotation, so it would look a bit smoother.
Thanks for the suggestions.
Thought some of you would be interested to know that walls are now solid. The first post has been updated with the
new link.
I wasn't planning on working on this anymore, but the other day I was really annoyed at the lack of collision detection, so I spent a couple of hours on it.
Nice! I like how it acts just like a PC first person game should, with different "wall sliding" speeds depending on your angle facing it.
EDIT: I see all the texture and map info is in the first post. How many 8x16 wall textures are you limited to using? Could you write a huge message on the wall?
UncleSporky wrote:
I like how it acts just like a PC first person game should, with different "wall sliding" speeds depending on your angle facing it.
That's actually a side effect of just adding one of the displacement components (X or Y), since the wall prevents the other one from being used. So I'd say this is the natural behavior, we don't have to do anything in particular for it to work like this.
Quote:
How many 8x16 wall textures are you limited to using? Could you write a huge message on the wall?
I think you can have 128 different types of walls (bit 7 is used to select between empty and solid, so only codes $80-$FF are solid blocks), each with its own texture. Enough for the whole alphabet, which means you can "type" whatever you want if each letter occupies a whole block. Also, textures can reside in RAM, which means they can be changed/animated (this is something I've been wanting to try).
tokumaru wrote:
UncleSporky wrote:
I like how it acts just like a PC first person game should, with different "wall sliding" speeds depending on your angle facing it.
That's actually a side effect of just adding one of the displacement components (X or Y), since the wall prevents the other one from being used. So I'd say this is the natural behavior, we don't have to do anything in particular for it to work like this.
That's what I figured, but it's still a nice effect.
Quote:
I think you can have 128 different types of walls (bit 7 is used to select between empty and solid, so only codes $80-$FF are solid blocks), each with its own texture. Enough for the whole alphabet, which means you can "type" whatever you want if each letter occupies a whole block. Also, textures can reside in RAM, which means they can be changed/animated (this is something I've been wanting to try).
Cool. I didn't think about animating at all when I made these:
Found this font too:
You were talking on previous pages about wall colors. I can tell from the way it's currently built that every wall must be comprised of one color which is dithered with black to show a darker shade. Is there any way to use less than 3 unique wall colors, but instead use two different colors for one wall? For example, A level with that has nothing but blue/green walls with no dithering?
When I saw those graphics, the first thing on my mind was "Which TI83 game is this for?"
I didn't really take into account how stretched things get, though. They'll probably look more like this:
UncleSporky wrote:
I didn't think about animating at all when I made these:
Very interesting textures! I should try some of them... would that be OK?
Quote:
I can tell from the way it's currently built that every wall must be comprised of one color which is dithered with black to show a darker shade.
Yes, that's correct. There's also some extra dithering to differentiate perpendicular walls... without that it would be pretty hard to make things out at that small resolution.
Quote:
Is there any way to use less than 3 unique wall colors, but instead use two different colors for one wall? For example, A level with that has nothing but blue/green walls with no dithering?
That should be possible. As long as the resolution (4 "pixels" per tile) and the color depth (1 bit per "pixel") are the same, the same logic could be used. The dynamic palette management not be necessary, so it would probably have to be disabled.
I'd rather keep the dithering that differentiates perpendicular walls though, because I really believe they help with the spacial perception a lot. But honestly, I think that a level where all walls use the same two colors would be pretty boring. I'd much rather have monochrome textures in more colorful levels.
Yes, feel free to use any of those as much as you like, it's what I made them for. I can try to make other ones if you need anything specific.
I'm going to have to try to make a wall sconce with an animated flame in it or something.
And yeah, I didn't think about the perpendicular wall dithering, you do need shading for that to help visualize the layout.
tokumaru wrote:
But honestly, I think that a level where all walls use the same two colors would be pretty boring. I'd much rather have monochrome textures in more colorful levels.
I don't know, the three bright blocks just feel odd to me. They'd definitely be good for forming a mental map of the level and representing different areas, but their forced monochrome just feels limiting to me. You can do a lot with even two different colors. Personally I wouldn't be averse to it for individual mazes/maps because I wouldn't expect a lot of color variation in a rocky cave or castle dungeon, but I guess it depends on how it ends up looking in the engine.
For example, a mossy rock wall sort of thing:
Or just using two different solid colors:
You could still show different areas by alternating the primary color you use in texturing. In fact I think it would be cool to use different textures to gradually dither the walls - you start in a dark purple room and as you walk down a corridor it fades to a light blue, etc.
Of course you can do that in monochrome too...it's your project, I don't mean to tell you how to do it.
EDIT: Here's an expanded castle set, with animated wall sconce:
Although the fire looks splashy, not flamey. I'll see if I can fix it.
Here are some more tries:
EDIT2: And here are some levers for opening doors:
EDIT3: And a skull!
Well will there be a next update with better graphics ? Because to say the truth, I am impressed that it's possible to do such 3D on the NES, but nevertheless.... it really looks terrible.
Wow, nice textures, UncleSporky!
Bregalad wrote:
Well will there be a next update with better graphics ?
I might try better textures (and colors), like the ones UncleSporky made, but the resolution isn't going to improve. I can barely sustain a decent frame rate as it is.
Anyway, this wasn't meant to look great. I knew the resolution would be very low from the start, but that was one of the characteristics that made my design possible.
If anyone else has different ideas on how to implement a raycaster that will allow for more resolution/colors, I'd love to see that (this is not sarcasm or a "challenge", I'd really like to see that).
Well like I was saying a while back (I don't remember when this was), if you can implement a line drawing engine and XOR filling, you can just make wireframes out of each wall, and use XOR filling to fill them. This would take care of the resolution problem, but textures would still be an issue. You could also make wireframes out of simple shapes on each wall, and then fill those. That might take too much processing time, and look really stupid though.
I know I don't post around here much, but I'd be very interested in making a game out of this if you could get it to work. I've had an idea for a game I'd like to do for quite some time now.
Celius wrote:
Well like I was saying a while back (I don't remember when this was), if you can implement a line drawing engine and XOR filling, you can just make wireframes out of each wall, and use XOR filling to fill them. This would take care of the resolution problem, but textures would still be an issue. You could also make wireframes out of simple shapes on each wall, and then fill those. That might take too much processing time, and look really stupid though.
This is possibly a bit unrelated, and I know wireframe games are not unknown on old consoles (stuff like Elite) but I was just informed of this Gameboy game called X that I think looks pretty cool:
http://www.youtube.com/watch?v=pbtmBQIKTh8
http://www.youtube.com/watch?v=WCyTGdCyg3w
A DSiware game called X-Scape just came out which is apparently a sequel.
X was also the first game to contain "K.K. Song", a song that has shown up in numerous games for which Kazumi TOTAKA has composed music. (Mario Paint was the second; click the O at the title screen to hear it.) Why do I mention this? Jeroen knows.
I remember hearing about this but never quite got to check it out till now... and I must say WOW! Looks excellent! I'm only poking at it in an emulator, I can only imagine how exciting it is to see it coming from the console.
tepples wrote:
Jeroen knows.
I sure do.
Whoa!
Congrats,Tokumaru.
Really hard to belive for me what's NES is compable of when smart peoples mess with it.
Again,Congratulations,and keep good work;)
Tokumaru, somebody made a raycaster for the ColecoVision that appears similar to yours.
http://www.youtube.com/watch?v=V3SFKZau8G8
Looks like they have the beginnings of a game there, with a map and menu. If they can do that on CV, I bet you can do something better on NES!
But then the ColecoVision has almost the same CPU as a Game Boy, which runs FaceBall 2000.
naI wrote:
Tokumaru, somebody made a raycaster for the ColecoVision that appears similar to yours.
Interesting... I really like to see these old machines running raycasters. The basic engine in this isn't very advanced (yet?) though... The walls are not textured (this is one of the biggest speed killers in my engine), they get jagged a lot (this happens when you use little steps for the rays instead of precalculating larger steps, because of rounding errors) and are fisheye distorted. If they fix these issues this game is gonna be much more interesting!
Quote:
Looks like they have the beginnings of a game there, with a map and menu. If they can do that on CV, I bet you can do something better on NES!
I could probably use my engine in a game, but I'm sure the frame rate would drop noticeably, and I find slow games annoying. My current idea for drawing sprites doesn't look very promising, since I couldn't think of many tricks to speed it up like I managed to do with the walls, so I'm afraid of how much they will affect the overall performance. I'll never know if I don't try, I know...! =)
tepples wrote:
But then the ColecoVision has almost the same CPU as a Game Boy, which runs FaceBall 2000.
But at a lower clock speed, right? Also it has less RAM. By comparing this raycaster to mine, and the features that each one sports, I think the NES has the upper hand here. I still think the CV has a lot of potential, and I'm definitely curious to see how far this project goes. They can probably display much more colorful screens than I can, in case they decide to add textures and stuff.
tokumaru wrote:
tepples wrote:
But then the ColecoVision has almost the same CPU as a Game Boy, which runs FaceBall 2000.
But at a lower clock speed, right? Also it has less RAM.
ColecoVision, ZX Spectrum, Master System, Game Gear: 3.58 MHz Zilog Z80
Game Boy: 4.19 MHz Sharp CPU similar to Z80
I guess the difference between a Spectrum (which can run
an impressive textured FPS) and a ColecoVision isn't the clock speed as much as the fact that (as you pointed out) the Spectrum and Game Boy have a poopload more RAM.
tepples wrote:
I guess the difference between a Spectrum (which can run
an impressive textured FPS)
I'm not sure that's a raycaster though... Still impressive, of course.
Quote:
and a ColecoVision isn't the clock speed as much as the fact that (as you pointed out) the Spectrum and Game Boy have a poopload more RAM.
I seem to remember that the video memory is directly accessible by the CPU on the Spectrum, is that correct? That probably makes display manipulation faster.
Technically, the ColecoVision could display something as colorful as
M.O.O.D., which is an advantage it has over the NES.
This would make a good world view for a port or remake of Alternate Reality. I love those games. Mostly played 'The Dungeon' but couldn't find any good clips of it..
http://www.youtube.com/watch?v=aIsRiUgT_zo
I'm sorry if I'm trying to bring this thread back from the dead, but there's no evidence that the project has been totally abandoned, and Duke Nukem got released, so...
I made a similar spriteless raycaster in Qbasic/QB64 and I think it would be really cool if this could be made similar. I'd be willing to give source, as long as I got credit. As I said, no sound or sprites are needed, so it just might fly on the NES!
Here is a video of my program.
http://www.youtube.com/watch?v=y1qiQRDeEU0
So the goal is to avoid the blocks that come at you? I am not too fond of this idea because it removes two things I consider essential: the ability to turn left and right and the freedom to explore.
It should be possible to come up with some other kind of gameplay that does not require objects to be placed in the maze... You can have a gun and shooting walls is definitely a possibility, so maybe something interesting can be made with those elements.
I do want to add objects eventually, but there would be at most 2 or 3 objects in a room, otherwise the speed would drop too much.
Did you have some clever solution to tunneling? I'm playing with a NES raycaster, and at some angles I have really tight tunneling - dropping the increment to very low values would be a fair performance hit.
I did not have that problem at all. We're probably using different techniques for casting the rays.
You might cast both an X ray and a Y ray and use whatever hits closest. Or when the ray enters each cell, you might check whether both X and Y have changed and check the adjacent cell if so.
tepples wrote:
You might cast both an X ray and a Y ray and use whatever hits closest.
This is what I do. I cast 2 rays, X and Y, extending the shortest one each step, and testing whether a wall was hit. I never detect the wrong wall this way.