http://www.youtube.com/watch?v=mgRffJtbYeM
Pretty sure this is more fake than a pirate's wooden leg.
Am I right?
Looks fake (mostly because of resolution and object scaling), but something like that is pretty doable on the NES. The logic for calculating distances to walls and figuring out their height in a raycaster is pretty simple, the NES can certainly do it if the number of columns is not so high. Since the walls don't have textures, a few tiles with different angles would be enough for drawing all sorts of walls.
Well, all we have are two videos from two years ago. The username doesn't show up anywhere on google aside from in relation to these two videos (hosted/posted on various sites).
His comments seem to show a realistic amount of knowledge:
Quote:
Homebrew port of doom
Still a work in progress
Programmed for the 6502 microprocessor with NESHLA from bripro.com
I need programmers who are good at sound in assembly, and about anything else
I'll post more videos once improvements are made
The goal is to Convert the entire shareware episode of doom
(regarding whether textured walls will be supported)
Quote:
At this point, I'm gonna say no. The SNES version of doom handled textured walls with varying results. At this point, this is just a very minimal 3d engine supporting filled polygonal walls, and as far as the engine goes, that's the way it'll probably stay.
He made this offer in the Youtube comments, so perhaps there is at least one ROM file floating around out there somewhere:
Quote:
I don't plan on selling it.
I have it up as a NES ROM (*.nes format).
If anyone wants it, I can send them a link in private message.
His profile says he's 23 years old and from Afghanistan. This has led Youtube posters to assume he has died, since he is from the Middle East. Perhaps less than logical, though it is true he hasn't signed in for a year.
As to whether what he showed is possible? I would say yes. The enemy and barrel scaling might be difficult, but the walls are pretty simple, nothing but straight lines. There are no divisions between walls, no lighting, only a single flat perspective. If it was fake I would expect to see some really obviously broken rules, but I'm not seeing that here. Heck, I've seen
more complex 3D posted here (
ROM).
Well like tokumaru said, it looks like scaled graphics/sprites, which isn't possible.
I don't think it could render that fast either.
It looks like he took this Game Maker DOOM demo and just changed the sprites and everything, imo.
The walls could definitely render that fast. Scaling, I don't know.
Never say something is impossible; I can imagine several ways you might accomplish scaling, though perhaps not on this level. A really crazy person might go ahead and have a full bank for each slight movement. Unwieldy, yes, but possible.
I was able to pause on a frame where he was up close to the enemy and I admit
it looks pretty suspect. The edges of the enemy seem extra fuzzy as if it were a texture up close and not a pixel-perfect NES image (the gun and wall edge are much clearer). But at the same time, this is a low res youtube video that can render things funny at times.
There's also a strange issue where the edges of his scaled images are slightly transparent, or have a blue edge to them:
I think I've seen this on sprites before online (gifs), though I'm not sure what causes it. Manual editing that misses pixels, or scaling in an image editor perhaps. Is there any reasonable explanation for these artifacts to occur on a NES? Supposing he actually found a way to do scaling, could it be misaligned sprites or something? The blue parts aren't uniform every time we see the enemy.
The Youtube video codec (or whatever it is they're using; could be some native Flash codec) is probably responsible for what you're seeing there.
It does seem like it's the background color (floor and ceiling) showing up, it doesn't look like video compression artifacts.
The weirdest thing I see is the very smooth object scaling. The bitmaps have very low resolution, yes, but they seem to be scaled every frame, something that would require complete recalculation and updating of many tiles, and that just can't be done that fast.
As long as no *.nes file is made, there is no reson to make any speculation on something that might be fake. Altough it's not as abovious as the FFX one. It might as well ne be a fake, but in this case who cares since there haven't been much progress on the game.
Bregalad wrote:
who cares since there haven't been much progress on the game.
You have a point. A square room with 2 things to shoot isn't exactly a very exciting port of Doom.
tokumaru wrote:
The bitmaps have very low resolution, yes, but they seem to be scaled every frame, something that would require complete recalculation and updating of many tiles, and that just can't be done that fast.
Don't underestimate the power of 8-bit machines. Something as sparse as this could most likely be done demo-style, with highly optimized routines and some degree precalculation (perhaps, for example, he has in ROM the enemy "sprites" scaled to a few interim resolutions so that scaling can be done more efficiently at smaller sizes).
Sure, the NES can't do DOOM proper. It could definitely handle a DOOM-style game with simplified graphics and sound, with the right coder behind it. Look at all the C64 demos that have simple DOOM-style parts, and they generally use redefinable characters rather than bitmap mode so it is comparable to the tile-based NES.
C64 != NES. NES doesn't have some of the luxuries of the C64 like local mapped VRAM and direct access during active display, etc.
LocalH wrote:
Don't underestimate the power of 8-bit machines.
I'm the last person to do that! =)
Quote:
Something as sparse as this could most likely be done demo-style, with highly optimized routines and some degree precalculation
That was my approach back when I was designing my own raycaster. I couldn't figure out anything good for object scaling though. In real time that's tough, because scaling objects is a 2D process, while scaling walls is a 1D process.
Quote:
(perhaps, for example, he has in ROM the enemy "sprites" scaled to a few interim resolutions so that scaling can be done more efficiently at smaller sizes).
I agree that it should be possible somehow, I just don't think it would look as smooth as in that video...
Quote:
It could definitely handle a DOOM-style game with simplified graphics and sound, with the right coder behind it.
I believe it can do Wolfenstein 3D pretty decently. DOOM relied on stairs, elevators and other things that I think are just too much. Although I guess that many times people use DOOM to describe the style just because it was more popular than Wolfenstein.
Quote:
Look at all the C64 demos that have simple DOOM-style parts, and they generally use redefinable characters rather than bitmap mode so it is comparable to the tile-based NES.
Defining too many patterns on the fly is a pretty sluggish thing on the NES. I believe that if a playable raycaster ever shows up on the NES, it will use pre-calculated patterns. I'm not saying the other way is impossible, I just have more faith on the pre-defined patterns.
You know, it's actually possible for the walls to be that resolute if you use a little raycasting to determine the heights of each end of each wall displayed, and then use a line drawing routine to draw from one end to the other. Then you can just use XOR filling to fill between the lines (making the walls a solid color), so you're basically doing polygonal stuff but with VERY limited 3D calculation. That of course would require use of CHR RAM and dynamic tile drawing. The good news is you would hardly ever have to copy over more than 64 tiles of CHR data (Since that's about as many tiles as the lines would require to be drawn), so it wouldn't be so bad in terms of causing slow-down (you would probably have to do a fair deal of artificial blanking though). Perhaps I'm missing something, but I think this would be a pretty good alternative to casting for each column. I'm not quite sure about enemies/objects though...
I'm going to have to call bullshit on this, if only because there are some colors in there that aren't quite possible on the NES.
Now, if it looked more like this:
http://www.youtube.com/watch?v=X3Oqz5WjDPI, I'd be a bit more impressed.
Though I'm certain a raycasting engine such as that is very possible to do on the NES I believe that one is fake unfortunately.
The hand with the gun is 3 colors, so when it overlaps both the green and the blue it's 5 colors. So the hand and gun cannot be rendered using background tiles but would have to be sprites layered above the background.
If it is sprites, there is no reason to give it such low resolution other then to make it look lowtech.
I know it's not NES buuuut... who thinks this is possible?
http://www.youtube.com/watch?v=G27pO38Z3l0
Very conspicuous that they're using Affine transformations on the textures there. Not perspective correct. Nauseating to watch.
The GBA already got two ports of Doom anyway.
Anders_A wrote:
If it is sprites, there is no reason to give it such low resolution other then to make it look lowtech.
It might have been an artistic decision. When I was designing a NES raycaster, I pixelated the hand on purpose so that it wouldn't look so different from the low resolution background. Even the original Wolfenstein 3D does this. It's just so that the different types of graphics blend well together.
Obvious fake. When he says "The goal is to Convert the entire shareware episode of doom" you know he doesn't have a clue.
Yeah this demo is definitely fake. But in terms of raycasting on the NES, that is not entirely unheard of, check out badc0de's "Stuck in Castle Nessenstein"
http://jiggawatt.org/badc0de/console.htm
http://jiggawatt.org/badc0de/sicn.nes - Run in PAL emulation
You can see the 8x8 tiles pretty clearly when you get up close to a wall, but from a distance its very impressive. Adding objects with perspectives would be a challenge though, because you'd need a different set of 8x8, 16x16, 32x32 tiles for each distance, which would pretty much eat up all your sprite resources.
For a raycaster, it would be possible to have a game with CHR ROM if you used 4x4 pixels and had every color combination pre-defined (every combination of 4x4 pixels for 3 colors fits into 256 tiles). Then you wouldn't have to worry about doing CHR data transfers and you could just do NT updates. That might be more beneficial for when you have to scale complex objects, simply because it's easier to deal with only NT updates and not CHR updates. It would greatly reduce resolution, however.
Celius wrote:
It would greatly reduce resolution, however.
Then again, what would be the point of having more resolution if that would make the game dead slow? Casting the rays is already kinda slow, scaling the textures is quite slow too. With too much resolution not only will you have to do those steps with many columns more, you'll also spend too much time drawing patterns and updating them.
Also, using CHR-RAM would force you to reduce the viewport because of the limited number of tiles, IMO killing the point of having better resolution.
I believe that a CHR-ROM-based raycaster should be quite playable on the NES. Something like Celius said (which would look similar to
this demo - download and change the extension to ZIP) could work, but the low vertical resolution bothers me a bit. I prefer to have more vertical resolution and less horizontal resolution, which even reduces the number of calculations to perform, and it could look like what I posted in
this thread. This is my favorite option, I must say.
Another option that also works with CHR-ROM is something that looks like
this demo (again, change the extension to ZIP). The resolution is better, but there are no textures and there are only two colors for walls.
There are several ways a raycaster could be made on the NES using CHR-ROM, and some of them don't even need all 256 tiles. With my favorite way I managed to leave 80 free tiles, enough for borders and a decent interface, and the other half of the pattern table is 100% free for sprites.
Quote:
I believe that a CHR-ROM-based raycaster should be quite playable on the NES. Something like Celius said (which would look similar to this demo - download and change the extension to ZIP) could work, but the low vertical resolution bothers me a bit.
The demo looks nice as a demo (imagine you're playing this on a NES, but of course you didn't want to code it in 6502 to gain time), but honnestly in a game it would actually look pretty lame. Again my opinion find that all FPS looks lame until you stand at like 10m of the screen.
Quote:
I prefer to have more vertical resolution and less horizontal resolution, which even reduces the number of calculations to perform, and it could look like what I posted in this thread.
You are right, you could make use of 256 tiles of 2x8 "textels" instead of 4x4, or use regular nametable changes to increase the resolution. I wrote once a demo that does that and my it was so much of a pain, I had code that does linear transformation *and* timed $2000 writes at the same time. Would definitely be better with an MMC3.
I think if someone were to make a new raycaster for the nes, the "challenge" would be to have it playable in NTSC mode.
Seriously, there are too many PAL-only demos.
Drag wrote:
the "challenge" would be to have it playable in NTSC mode.
Not really. If CHR-ROM is used, only the name table will have to be updated. Since the game cannot run at 60 fps anyway because of all the calculations needed for walls and objects, the data doesn't need to be dumped to the PPU all at once either.
Say, if the game runs at 15 fps, the display will only change every 4 hardware frames, so we have 4 VBlanks to update the hidden name table. That's enough to redraw a very big portion of it, certainly enough for the 3D view and the HUD.
As I see it, the only advantage of PAL hardware is the extended VBlank, which, according to the explanation above, isn't really necessary. Castle NESsenstein probably needed PAL because it's logic is faster (seeing as there are no objects, textures or even fisheye lens correction) and draws the whole name table at once.
Perhaps it might look stupid, but it's possible to have increased vertical resolution for the raycasting part and use 4x4 pixels on the sprite half of the pattern table. But once an enemy gets really close up, they would probably take the entire sprite page to be drawn, so maybe it's a good idea to use the BG for enemies and use all 4x4 pixels. Though I still have a feeling it would work/look pretty cool to have CHR RAM and use really minimal 3D calculation to draw the walls as wireframe models and fill them with XOR filling. I totally think you could do it and have it run at 12 FPS. That way you can have perfect horizontal and vertical resolution.
Well I've noticed that it just honestly can't be real.
I KNOW the NES can display some crazy stuff, but there is no way it can display perfect resolution ray casting at 30 or 60 fps.
That's the first thing I noticed that had to mean it was fake.
The second thing is what some others said. The sprites. The NES has a sprite limit, and it's not possible to stretch sprite images, though it may be possible to stretch an image and the render it as sprites? I donno I suck at this stuff but I know enough of it to know what's real and what isn't.
It can't be part of the background either because it would be displaying more than 4 colors on 1 tile.
This guy is the carlos mencia of NES deving. Total fraud.
CKY-2K/Clay Man wrote:
This guy is the carlos mencia of NES deving. Total fraud.
Mencia didn't pop up out of nowhere without fanfare and disappear forever a few days later.
First imagine these three things:
- The TV adapter for Sega's Game Gear.
- FaceBall 2000 running on the Wide Boy, an early prototype of what would become Nintendo's Super Game Boy accessory.
- A Super NES game with a Super FX coprocessor.
Now imagine a microcontroller on the Game Pak rendering textured polygons into a frame buffer. For each 8x1 pixel sliver, it reads the pixels from the frame buffer, decides which of four palettes would best represent that sliver, and sends the palette ID and eight pixels. Done poorly, the attribute clash would look like the ZX Spectrum. Done well, it could look better than the MSX.
But it's fake unless the video's author can prove he went to all that trouble.
He's back.
I made a video of that Stuck in Castle Nessenstein demo.
http://www.youtube.com/watch?v=tPlZI1OTSvY
He comes back on and posts "fake?"
Anyways he's still alive.
I asked him in a PM why he's doing all this. Trying to get attention from people through some crappy edit of a Game Maker example.
I really, really. think it was done throughout this DOOM Game Maker example findable on the site. Same physics and aspects and all.
Well there is
worse when it comes to fakes.
Reading people comments makes me really pissed of.
Bregalad:
I thought that was a really cool animation actually. And I doubt the intent is to fool anyone that's it's running on the NES. (and if it was, then I congratulate the creator on teasing naive minds)
Yes of course this intro is really cool !
Here is the "real" one by the way.
Altough it looks like that, yes, the author did mention it like if it was running on a NES. He talks about a "NES" version and not a version with NES graphics. Seeing the comments below is really confusing like "the NES would explose if it had to do it"... it's just SO untechnical, hopfully this was a joke
Hey guys. Here is a
flash prototype of the raycaster I've been planning for a while (there is no collision detection, so try not to go outside of the map). The NES can surely do this, the only question is how fast...
In this prototype I'm using the same fixed-point precision and texture scaling as I would on the NES, so a ROM would look exactly like that. With some tricks I was able to reduce all coordinates to 16 bits (as opposed to the previous 24), but the maximum map size is 64x64 blocks (the prototype map is 16x16), although it should be possible to have map transitions or different floors in a real game to have larger levels.
I also simplified the texture scaling to use only 8-bit integer calculations, so it should be pretty fast now. Drawing larger walls is slower, but since finding them is faster (because they are closer the ray doesn't extend much) there shouldn't be much difference compared to smaller walls (which are faster to draw but slower to find).
Anyway, I think this looks interesting for the NES, even though the textures look pretty mangled when seen from a distance. Do you think it is too ugly or is there any interest in seeing this on the NES? I'm considering making a 3D shooter for the NES, but I have to know if you guys would cope with the low resolution.
Well it should be very interesting for a tech-demo, but to be honnest I don't see myself sitting hours in front of such poor graphics. But again 1st preson FPS are the only games I really have trouble to enjoy anyway even those with better graphics so...
Bregalad wrote:
1st preson FPS are the only games I really have trouble to enjoy
Yeah, this wouldn't be anything revolutionary in the gameplay department, it would be as basic as Wolfenstein I guess, so you probably wouldn't like playing it.
I've always had an interest in raycasters, and enjoyed looking for implementations across different systems (specially the older ones, older than the raycasting technique itself), and liking the NES like I do I always felt bad there were no proper raycasters for it (the author of "Stuck in Castle Nessenstein" will excuse me, but it's full of glitches and it's PAL only - if I can't play on my NES it's not a NES game).
So yeah, I might try this, even if the gameplay isn't very innovative. I'm not really sure about how to handle sprites yet though. If I use 8x8 I'll not be able to draw much, if I use 8x16 I won't be able to pre-render them with all possible patterns. I might end up making a few reusable parts (as opposed to every possible pattern) that objects are required to be built from which will be available in different sizes.
That's the other reason I suggested 4x4 pixels, because you could make sprites as part of the BG.
Celius wrote:
That's the other reason I suggested 4x4 pixels, because you could make sprites as part of the BG.
Yes, but that isn't such a good thing because you'll be limited to 4 colors for the entire view... So the enemies/objects would share the same colors as the walls, which would look pretty dull and wouldn't stand out much. You may have seen some previous tests of mine that used 4x4 pixels. I gave up on that idea mostly because of the following reasons:
1. 4 colors for everything is too little, the levels were too dull, they lacked "life";
2. the poor vertical resolution made distant walls too indistinguishable;
3. too many rays had to be cast because of the horizontal resolution, it would be almost twice as slow;
I know, 8x2 pixels have a great impact on the horizontal resolution and can fuck up the texturing of distant walls, but I still get a better sense of 3D then I did with 4x4. Considering that I can also have more wall colors and faster rendering, it wasn't hard to decide in favor of the new pixel size.
tokumaru wrote:
Anyway, I think this looks interesting for the NES, even though the textures look pretty mangled when seen from a distance. Do you think it is too ugly or is there any interest in seeing this on the NES? I'm considering making a 3D shooter for the NES, but I have to know if you guys would cope with the low resolution.
Yeah I like it. I'd say definitely go for it.
I see your point. 4x4 pixels are awfully big, and for details/small things, they are undesirable. Though for sprites, if you make them part of the BG, your graphics will look a lot like Atari 2600 graphics with very wide pixels. Let's see some pros/cons of working with BG/sprites.
BG Pros:
-Anything made of 4 colors and 8x2 pixels can be displayed. ANY.
-No size limits (besides 1 pixel for being as small as possible)
BG Cons:
-8x2 pixels on enemies/objects are very Atari 2600 seeming, maybe worse.
-Only 4 colors
-More time consumed computing final image, layering enemy graphics over the raycasted walls
Sprite Pros:
-Enemies can be placed anywhere on screen
-Pixel size is not an issue, necessarily
-Drawing sprites is easy compared to doing it with BG
Sprite Cons:
-Could be very hard to stay within the 64 sprite limit
-Could be very hard to stay within the 8 sprites per scanline limit
-Possibly hard to have all sizes and combinations predefined in 2BPP CHR format without eating too much space
-If there are too many predefinitions graphically, one might consider using CHR RAM, in which case, VRAM updates would be horribly time consuming
I think if you can't stand the way 8x2 pixel enemies look, you'll have to stick with sprites, it seems. It might be possible to do a combination of the two, and use sprite layering over the BG for 8x2 pixel sprites. Though you'd have to be clever as to not ever go beyond sprite scanline/page limits. Then there's always flickering, so you can display one enemy, then another, then another, etc. cycling through them all. I think it wouldn't be SO hard to make sure an enemy stays within 64 sprites. You might have to make them 8x16, as well as reduce their size.
And enemies don't necessarily have to take up the entire screen if they're as close as possible. I would suggest, if you haven't, seeing how large you can make an enemy with 64 sprites. If you can make it so it looks pretty close, then that's good. You can then use the cycling method, or at least consider it. Otherwise, I'm not quite sure what to tell you... Perhaps the sprite+BG thing, but that could look weird...
Quote:
-Anything made of 4 colors and 8x2 pixels can be displayed. ANY.
Well, if you use MMC3 (or whathver better mapper) IRQs so that you toggle $2000.0 at lines 2, 6, 10, 14, 18, ... (each 4 lines) you can get 4x2 pixels on the whole screen.
tepples wrote:
How does FaceBall work?
Slowly.
EDIT: I checked the Gameboy version and it appears to redraw all the patterns every (logic) frame.
From the looks of it, it isn't a raycaster. It more likely calculates the positions and distances of the 2 points that form a wall section relative to the player and draws straight lines at the top and bottom connecting them, then fills the whole columns. It also seems to ignore distant walls.
This is a valid technique, but FaceBall isn't something to draw inspiration from, IMO. It runs at, what? 2-3 frames per second? It's very annoying. The same technique is much faster on the SNES, but I'd expect the NES to be more similar to the GB.
Celius wrote:
And enemies don't necessarily have to take up the entire screen if they're as close as possible. I would suggest, if you haven't, seeing how large you can make an enemy with 64 sprites. If you can make it so it looks pretty close, then that's good. You can then use the cycling method, or at least consider it.
Now you are thinking like me. =) The NES always had flickering for objects, so it shouldn't be so weird in a raycaster.
To keep objects from getting too big, enemies could have some sort of AI to walk away from the player when he's too close. I've also seen games (Zero tolerance on the MD/GEN maybe? Can't remember) use pretty large hitboxes for the characters, so it's impossible for them to be too close.
Static objects should not be tall and should be attached to the floor or the ceiling, so that they get out of view if you're too close. Only very narrow objects should be tall, and even then the large hitbox should be used.