My NES raycaster - ROM link inside!
Moderator: Moderators
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
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
-
- Posts: 2158
- Joined: Sun Jun 05, 2005 2:04 pm
- Location: Minneapolis, Minnesota, United States
- Contact:
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.
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
http://www.youtube.com/watch?v=Dwj_1Dngzio
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.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 .
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.If the sprites are pretty clear, then I stand by my statement. If the sprites are really blocky too, I might reconsider.
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.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 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).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)?
Thanks for the interest guys. Let's see how far I can go with this!
No way! =)strat wrote:You think it could have textures like 8-Bit Killer?
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.
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.
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.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.
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.
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.If it works well you could even add some inertia to the player's movement
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.
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.
-
- Posts: 388
- Joined: Sat Nov 17, 2007 8:44 pm
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.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.
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).How many 8x16 wall textures are you limited to using? Could you write a huge message on the wall?
-
- Posts: 388
- Joined: Sat Nov 17, 2007 8:44 pm
That's what I figured, but it's still a nice effect.tokumaru wrote: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.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.
Cool. I didn't think about animating at all when I made these: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).
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?
Last edited by UncleSporky on Mon May 24, 2010 6:18 pm, edited 1 time in total.
-
- Posts: 388
- Joined: Sat Nov 17, 2007 8:44 pm
Very interesting textures! I should try some of them... would that be OK?UncleSporky wrote:I didn't think about animating at all when I made these:
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.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.
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.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?
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.