This is my "what if F-zero or Mario Kart were made in 1985" idea. About 1 year of planning and about 2 days of actual programming.
https://youtu.be/vn7xwTau7s0I was only able to calculate half of the road per frame... and still have enough frame left to play music and move some sprites (later). It would probably look better with a much bigger racetrack.
Edit, changed title.
Interesting! Reminds me of this:
https://youtu.be/7Nw3OL4-tw4But the resolution is way too low... Do you think you can improve it and still have it run smoothly?
I was going to do a second pass over the data and do a "smoothing", and that pass could put edges as well... but I don't think I have the processing time. Currently it takes a (worse case scenario) 200 scanlines to process 1/2 of the picture.
I would have to drop down to 15 fps to do much more.
Unrelated, I could make a nice scrolling text demo, or scrolling logo / title screen with this method.
What frame rate does
F-FF run at?
I hate to be negative when criticising, especailly after all the effort you put into this project. However this really looks awful. Rendering is inapropriate for racers as it's way too slow. Simulate a pre-rendered road by distorting it is the standard way to do it. Look at Rad Racer, it actually looks quite good and convincing. I was expecting something like that when I clicked on the link. So yeah... that's what a Mario Kart or F-Zero would have looked like on the NES.
Sure Rad Racer uses the MMC1, which is a "special chip", but actually it doesn't use much of the chip, and it uses it mainly for extra memory, so if the game was single-level it could have fitted a NROM cart easily. For a NROM racer from 1985, look at F1-Race (the road is only distorted horizontally, not vertically, as it probably wasn't understood how to do this with the NES at this date).
Yeah, but we already have seen dozens of instances of using raster effects to fake 3d.
Bregalad wrote:
Simulate a pre-rendered road by distorting it is the standard way to do it.
The standard way is also the boring way. I'd rather see something unique, even if it doesn't look great.
I thought it looked great. I mean, afaik dougeff isn't an artist, I'm talking about the programming of the thing. It looks like real mode 7, at low resolution, ok.
I think one improvement that may be simple to add is to add different tiles depending on depth (screen y coordinate, really). It can be used to simulate distance.
tepples wrote:
What frame rate does
F-FF run at?
30 FPS for 1 player, 20 for 2 players
Quote:
I think one improvement that may be simple to add is to add different tiles depending on depth (screen y coordinate, really). It can be used to simulate distance.
Oh yeah and attributes + a few palettes are trivial for this effect too.
dougeff wrote:
This is my "what if F-zero or Mario Kart were made in 1985" idea. About 1 year of planning and about 2 days of actual programming.
https://youtu.be/vn7xwTau7s0That looks a bit blocky.
If you are already overloading the CPU with 16x16 "pixels" then I am wondering if you are using loads of multiplications or divisions per pixel?
Essentially, a scanline should be rendered by computing the x/y source steps, and then reading the source data with that steps (ie. using only step additions for the source coordinates, no multiplications or divisions within scanlines).
For the separate lines, I think you could re-use the same x/y steps, multiplied by a scaling factor for the distance. So there isn't too much complicated maths required, the main bottleneck would be reading source pixels, merging them to bitplanes, and writing to VRAM.
When using a huge ROM you could store the source data as uncompressed bitmap with 1 byte per pixel - of course that would have been expensive in 1985, and the required bank switching could also slowdown things, so you might find a better & cheaper way.
Quote:
16x16
8x8. It just doesn't use the whole screen. The final picture is 20x20 tiles. I tried 22, but it was too slow.
Quote:
loads of multiplications or divisions per pixel
Pre calculated LUT of sine and cosine for every 3° at 10 different distances. Each pixel is added to a base x,y (2 16-bit adds), and then indexed on a map.
dougeff wrote:
Pre calculated LUT of sine and cosine for every 3° at 10 different distances. Each pixel is added to a base x,y (2 16-bit adds), and then indexed on a map.
I have considered doing floor casting that way in my raycaster, but combined with wall texturing that would've been insanely slow. So I settled for blocky floors instead, because instead of doing calculations for every screen pixel, I only need calculations between block boundaries in the map.
If you don't need too much detail on the floor (based on your test map it doesn't look like you do), you might be able to get away with checking only grid boundaries too. That should result in a decent speed bump, probably enough to increase the resolution.
No, I meant 16x16 tiles, aka 16x16 low-resolution pixels. Oh, or is it even 20x20? Excluding the sky, that would be 20x10, or 200 pixels per frame.
So you would need 400 additions, and indexing for 200 pixels and a few dozen multiplications per frame.
I think you could reach maybe around 100 frames per second at that resolution.
But the framerate would drop rapidly when increasing the resolution, unless you drop the per pixel texturing.
With filled shapes you might get similar quality as what you have now, but at much higher resolution.
Not sure about NES, but home computers did have some 3D games, like Elite, Mercenary, Driller. And I think there's also Doom for the Spectrum.
The advantage on NES is that it's about twice as fast as C64, so I am wondering if it could render some impressive graphics at not so bad framerate.
I think this is pretty cool! Honestly, the resolution is enough for it to be playable. If you somehow can get it up or smooth the edges with diagonal boundary tiles to make it seem like it has better resolution (the smoothing doesn't need to be meticulous either as long as it doesn't lie about the position of the boundary too much), that's a bonus. But you could probably work with this.
The obvious advantage of this method is that you can create tracks very freely, including sharp turns and intersecting paths. It offers something you can't do for the game design with raster effects alone.
It could also work for maze crawlers and tank games (with seethrough walls). I mean you could simply avoid the natural ideal and go for something more TRON-y, or assume the player has a birds eye viewpoint above hedges/walls.
Surprised not a single person here has mentioned RoadBlasters from Tengen/Beam Software. Like Rad Racer, it also uses MMC1 (in this case, 128KB PRG + 128KB CHR). I'm going off of memory so there's a large chance I'm remembering things wrong, but I think it used precisely-timed PPU writes and reads and/or certain bits in in HBlank, combined with palette cycling and a lot of CHR swapping to give the impression of road movement, plus providing a horizon. There's similarities in the implementation model to Rad Racer and Rad Racer 2, but the result is a lot more impressive given all the other stuff going on. Consider that it's an arcade port as well (and yes, the surrounding environment does have that palette cycling effect even on the arcade).
If you haven't played this game (or at least checked it our in general), I recommend doing so.
tokumaru wrote:
The standard way is also the boring way. I'd rather see something unique, even if it doesn't look great.
Might be "boring", but there's probably a lot of improvements or at least changes that can be made on what has already been done. It's not like Rad Racer or Roadblasters looks "perfect" or anything, but they get the job done. I can't for my life imagine a working racer game based on 8x8 huge pixels or anything in the like. And no, the demo does not look like mode 7. Mode 7 has blocky pixels only when zoomed in, not always.
Thanks for the input. I will do some improvements. Maybe unroll some loops, or inline some calculations, simplify some things, maybe drop to 20 fps, maybe have 3 layers of attribute/palette shifts or something for depth. Larger map. Etc. etc. So, maybe I'll pop back in a year when all that is done.
I think this is terrific. The deformed road technique is not perspective correct, while your technique can be.
You said you wanted 1985 technology, but if you're willing to upgrade to 1989 technology, you can use a mapper with a good scanline counter, like MMC3 or MMC5. That way, you can start VBLANK earlier than line 241, and end it later than line 263, giving you lots more time to update VRAM.
If you use MMC5, you might be able to leverage MMC5's 8x8->16 multiplier to speed up your tile lookups.
Unroll your loops if you haven't already. If you are double-buffering (swapping between the first and second nametables to update the screen), you can write fully unrolled LDA + STA "blts" with known addresses (no indexing) to update your buffers. Takes up more ROM, but if you're using MMC3 or MMC5, you have the space to do that.
You might also consider seeing how much more you can accomplish at 15 or 20 fps. Gamers back then were willing to tolerate low framerates for revolutionary graphics. The home console ports of Hard Drivin' have such low framerates that they look like slide shows, but they were made anyway. Once you have a nice looking result with actual game logic at 15 or 20 fps, you can pick all of our brains for ideas of how to optimize it back up to 30 fps.
A lower framerate would enable 8x8 map tiles instead of 16x16 tiles, and that would look way better (it is 4x the resolution, after all). You can use MMC5's extended attributes mode for that.
Bregalad wrote:
Sure Rad Racer uses the MMC1, which is a "special chip", but actually it doesn't use much of the chip, and it uses it mainly for extra memory, so if the game was single-level it could have fitted a NROM cart easily. For a NROM racer from 1985, look at F1-Race (the road is only distorted horizontally, not vertically, as it probably wasn't understood how to do this with the NES at this date).
The MMC1 ability to switch between horizontal and vertical mirroring was used for Rad Racer. This let the sky wrap horizontally on a 1-screen wide area of the nametable, while allowing a 2-screen wide portion of road for the bottom area of the screen. (Layout described here:
https://forums.nesdev.com/viewtopic.php?f=2&t=8588)
The FDS had the same capability. I think the Japanese version was originally on (or partly developed for) FDS? Can't recall.
Rad Racer 2 uses 4-screen instead, which bypasses that need for different mirroring types.
koitsu wrote:
Surprised not a single person here has mentioned RoadBlasters from Tengen/Beam Software. Like Rad Racer, it also uses MMC1 (in this case, 128KB PRG + 128KB CHR). I'm going off of memory so there's a large chance I'm remembering things wrong, but I think it used precisely-timed PPU writes and reads and/or certain bits in in HBlank, combined with palette cycling and a lot of CHR swapping to give the impression of road movement, plus providing a horizon. There's similarities in the implementation model to Rad Racer and Rad Racer 2, but the result is a lot more impressive given all the other stuff going on. Consider that it's an arcade port as well (and yes, the surrounding environment does have that palette cycling effect even on the arcade).
In terms of 3D racing rendering, I think it's inferior to Rad Racer. The road is flat (no "hills" like Rad Racer) and has an awkward looking "wide" vanishing point. I'm not sure whether to consider that palette cycling field a plus or a minus (kinda ugly, IMO, and the arcade did do something similar but it's much, much smoother... Rad Racer also used palette cycling in a similar way, but just for the road stripes.) The spinning car at the end of the race is kinda neat though.
Its gameplay is maybe slightly more interesting than Rad Racer... but honestly, I'd rather play Hang On than either of these.
Anyway, I think there's a lot of potential for unusual rendering techniques on the NES, and am glad to see another experiment like this, whether or not it immediately manifests as some killer racing game. Please keep on
trucking karting.
rainwarrior wrote:
The MMC1 ability to switch between horizontal and vertical mirroring was used for Rad Racer. This let the sky wrap horizontally on a 1-screen wide area of the nametable, while allowing a 2-screen wide portion of road for the bottom area of the screen. (Layout described here:
https://forums.nesdev.com/viewtopic.php?f=2&t=8588)
Ah nice catch, I forgot that, even though I deeply reverse-engineered Rad Racer at some point in my life.
Quote:
The FDS had the same capability. I think the Japanese version was originally on (or partly developed for) FDS? Can't recall.
Both versions were cartridge but the game was obviously developed with FDS in mind, being based on the engine of 3D Worldrunner which was originally on the FDS - lots of code left-over from the FDS bios, etc...
Quote:
Rad Racer 2 uses 4-screen instead, which bypasses that need for different mirroring types.
Speaking about Rad Racer 2, I think that, counter intuitively, it looks slightly worse than Rad Racer 1... The stripes on the sides of the road are really not my cup of tea. The carts and scenery looks better though.
Quote:
Anyway, I think there's a lot of potential for unusual rendering techniques on the NES, and am glad to see another experiment like this, whether or not it immediately manifests as some killer racing game. Please keep on trucking karting.
Definitely. But it should be an improvement on what already exists to be worth doing, IMO.
The road looks like it is curving up
************************----************************
**********************--------**********************
******************----------------******************
**********--------------------------------**********
Shouldn't it be a straight line?
************************----************************
********************------------********************
****************--------------------****************
************----------------------------************
I think this looks really cool, and even as-is, I'd probably rather play a racing game like this than Rad Racer. It may not be the prettiest, but the gameplay could be worth it.
Nice work, and I'd love to see improvements on this.
Quote:
looks like it is curving up
The map is actually very small, so I manually adjusted the distances per tile. The top most tiles should be further away, but since the map is so small, it would usually be off the map (for the top few tiles), making the resolution look even worse.
Anyway, my manual adjustment was slightly off.
Agreeing with fiskbit. I think new gameplay possibilities on the platform trumps pretty graphics. And that’s coming from the impractical, details-obsessed artist.
I don't know why some of you are wasting time talking about raster distortion racers... That's the standard way to do racers in old consoles and it's been done to death. Some use more advanced techniques, some look better than others, but it's basically the same technique and that technique had nothing to do with what dougeff is doing.
mkwong98 wrote:
The road looks like it is curving up
Couldn't this be because of the fisheye distortion that results from calculating distances from the player in concentric circles against an orthogonal grid? That's what happens in raycasters, and you have to correct this by shortening distances for angles that are farther away from the middle of the screen.
In my raycaster I built this correction straight into the look-up tables, so I wouldn't need to do any extra calculations in real time. That drawback of doing this is that my look-up table of distances became 15x larger, because there are 15 angles on each half of the screen.
If your horizontal resolution is 20, your tables would have to be 10x larger to have the fisheye correction built-in.
Let's suppose it were possible to draw a 24x16 pixel mode 7 view at 30 fps. Would that be a usable resolution and frame rate?
I probably wouldn't play it at a resolution that low.
I would rather sacrifice frame rate for resolution. I think these tiny resolutions are fine for testing, but a real game needs to have a little more detail than that.
Just dividing each tile vertically into 2 pixels helps a lot by doubling the vertical resolution, and that's where detail is needed the most, so we can see what's ahead.
Dropping the framerate is fine for a FPS, but in a racing game the effects are really noticeable. 15 FPS looks absolutely terrible and choppy when the player is moving fast, and 20 FPS is only a hair better. Really, 60 FPS is what a racing game should run at, and 30 FPS is the 'okay' compromise.
Anyway, I don't mean to steal Doug's thunder, but did F-FF not have the right technique? I barely got any comments on it.
It didn't help that the game was hidden under a fake screenshot... A lot of people probably haven't even played it because of that.
tokumaru wrote:
I don't know why some of you are wasting time talking about raster distortion racers... That's the standard way to do racers in old consoles and it's been done to death. Some use more advanced techniques, some look better than others, but it's basically the same technique and that technique had nothing to do with what dougeff is doing.
What dougeff is doing doesn't even remotely ressemble a road. It looks like a bunch of legos stacked up eachoether. I know pretty graphics are not important, etc... But there we're to the point the resolution is so low it doesn't display anything reconizable.
I thought it was perfectly identifiable. Admittedly, the color scheme was a huge part of that.
I definitely agree that the resulution is too low as it is. I personally wouldn't enjoy a full game like this, I'd probably see it as an interesting technical curiosity. But people have different standards, and varying levels of tolerance for the different aspects of a game.
There'll always be people interested in all kinds of games, no matter how quirky or gimmicky they are.
I could probably hide the blockiness with some sprites for edges and detail.
pubby, f-ff was one of the games i had the most fun with in last years’ compo.
dougeff wrote:
I could probably hide the blockiness with some sprites for edges and detail.
I don't know if sprites are a good choice... Maybe you could do something similar to those upscaling filters (hq2x and such) and select each tile based on its neighbors... I wouldn't go full resolution, but maybe 4x4 pixels per tile would work well.
I think the concept behind this is really cool! It makes me want to try and do something like this on the Game Boy now
I have a few thoughts about the possibilities of "Mode 7" like graphics on the NES. If you do a water based racer instead of futuristic hovercrafts, you probably could get away with blocky graphics. It'd mostly be varying shades of blue, and the course could be delineated with sprites that look like buoys (although you'd have to move those in relation to the course as you move). You can also get away with dithered or striped tiles too to mark the edges. This will probably look better given that you'd stick to mostly blues, white, and possibly gray. The trick then is to make sure things don't look too bland.
Another idea, this might be interesting to see as a "3D" space shooter in a limited free-roaming environment. Not sure how feasibly it is to play around with the Y-axis in your demo, but stepping into a spacey genre would also open up the color palette so that things don't have to identify as a road specifically.
Shonumi wrote:
Another idea, this might be interesting to see as a "3D" space shooter in a limited free-roaming environment. Not sure how feasibly it is to play around with the Y-axis in your demo
So...
HyperZone?
dougeff wrote:
Quote:
looks like it is curving up
The map is actually very small, so I manually adjusted the distances per tile. The top most tiles should be further away, but since the map is so small, it would usually be off the map (for the top few tiles), making the resolution look even worse.
Anyway, my manual adjustment was slightly off.
How about pointing the camera slightly downward?
I think I'm going to take a break and learn GameMaker or something, so I can prototype this sort of thing easier.
Plus, my oldest son wants me make a game with him, and he's been drawing these giant detailed levels, with large enemies, and I think he's going to be disappointed with what I can make on the NES. So.. GameMaker.
https://youtu.be/1gO59rZrisQ(song, Sell Out, by Reel Big Fish)
For kids, nes programming is maybe too limited for them so using a tool like gameMaker is more appropriate. Later they can try by themselves if the nes interest them. I guess I should check about it since my kids wants to make games too
I had success making games with my 5-year old daughter using Scratch. She can't do it on her own yet, but she understands the general concept very well, and does actively work on the game logic with me. She learned about the Cartesian coordinate system for the first time, and even corrected me when we were coding and I used the wrong axis. She can use ScratchJr on her own though, but she creates mainly non-interactive stories, rather than anything that resembles a game.
dougeff wrote:
Plus, my oldest son wants me make a game with him, and he's been drawing these giant detailed levels, with large enemies, and I think he's going to be disappointed with what I can make on the NES. So.. GameMaker.
There's a "
buddy game jam" going on that my son has been asking about, where you make a game with an inexperienced person. If that's the sort of thing that interests you guys, you might take a look.