Another Raycasting Demo

A place where you can keep others updated about your NES-related projects through screenshots, videos or information in general.

Moderator: Moderators

tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Another Raycasting Demo

Post by tepples »

Espozo wrote:I know that there's no way you could ever have two mode 7 layers [on the Super NES], but just one and an extra, regular 4bpp layer.
Super NES VRAM allows one low-byte read and one high-byte read per pixel. The addresses of the two reads are the same except for mode 7 backgrounds. In mode 7, eight map reads and eight texture reads completely fill the time allotted to one sliver of eight pixels. One extra 4bpp layer would be one extra low-byte read and one extra high-byte read for the map entry and two extra low-byte reads and two extra high-byte reads for the pattern data for every eight pixels, for a total of eleven, which exceeds eight by three.

The GBA's PPU is connected to faster memory (four 16-bit reads per pixel) and thus you can have two tiled layers and one "mode 7" layer in mode 1.
tepples wrote:The GBA PPU can also retrieve multiple pixels at once from VRAM because VRAM is word-wide rather than byte-wide. It can't do this in mode 7
Doesn't this have to do with the fact that two neighboring pixels aren't guaranteed to be next to one another like they are in a regular tiled layer?
Yes.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Another Raycasting Demo

Post by Drew Sebastino »

tepples wrote:Super NES VRAM allows one low-byte read and one high-byte read per pixel. The addresses of the two reads are the same except for mode 7 backgrounds. In mode 7, eight map reads and eight texture reads completely fill the time allotted to one sliver of eight pixels. One extra 4bpp layer would be one extra low-byte read and one extra high-byte read for the map entry and two extra low-byte reads and two extra high-byte reads for the pattern data for every eight pixels, for a total of eleven, which exceeds eight by three.
How about a 1bpp layer? :lol: (admittedly, this could work for stars.) Oh yeah, the graphics format always assumes that the color depth is some multiple of 2bits. It was a silly idea anyway.
tepples wrote:
tepples wrote:The GBA PPU can also retrieve multiple pixels at once from VRAM because VRAM is word-wide rather than byte-wide. It can't do this in mode 7
Doesn't this have to do with the fact that two neighboring pixels aren't guaranteed to be next to one another like they are in a regular tiled layer?
Yes.
By this logic, do affine sprites take up twice as many sprite pixels per line, even not in the double sized (for avoiding clipping) mode?

You know, because we're talking about 3D graphics, how exactly does z buffering work? It seems the most logical thing to do would be to order all the polygons from farthest away to closest, but that's probably way harder than it sounds. What I imagine would be the best thing to do although you could only draw polygons in software if it isn't a hardware feature (which it probably is) would be to have every single pixel in the framebuffer have a "depth value". What this would do is if you were drawing a polygon, it would look at every single pixel in the polygon, and before it would look to map the texture on it, it would see if the depth number is below the number of the pixel currently occupying that spot. If the what is to be drawn pixel is below, it just doesn't draw anything and doesn't even bother looking to find the texture for that pixel. If the value is above, it actually looks for the texture for that pixel and draws it into the framebuffer. This could actually explain the "glitchines" that occurs when two textures are very close to one another, but aren't as large as each other (so their coordinates aren't exactly the same) It's like in that example thing you showed,there are "fluctuations" in how the line is drawn (because it can't be a perfect line)

Like in this picture below I made, if you're viewing the picture as if you were from the bottom (as apposed to the "aerial" view you're actually seeing it) it should be pretty obvious that the blue texture is just a hair closer to you, but if you were only looking at one pixel, you'd have no clue on certain pixels. The purple is where the blue and the red texture overlap. On the bottom of the image, it shows kind of what is actually drawn, because say if in a situation where two pixels two different textures are on the exact same spot, the GPU makes the pixel of the newly drawn texture have priority and overwrite the other, the red texture is the newly drawn texture.
Texture Priority.png
Texture Priority.png (223 Bytes) Viewed 10654 times
You know what would kind of make sense? Why not just blend the colors together like in the example above? It's still not pretty, but it's at least better than nothing.

Speaking of transparency, I just realized that this whole ideology I came up with completely falls apart when transparency is used... Actually, now that I think about it, I've seen in several games where if two transparent things are drawn over one another, only the one with the highest priority is displayed. That actually makes sense, as if it draws the higher priority thing first and then the lower priority, it will see the priority of the pixel is high, and it can't tell that there are two pixels being blended together because it's already been done and the result is in the framebuffer, so it might as well be any color. I guess there actually is some sorting for transparent objects?
Last edited by Drew Sebastino on Sat Dec 19, 2015 5:23 pm, edited 2 times in total.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Another Raycasting Demo

Post by tepples »

Espozo wrote:By this logic, do affine sprites take up twice as many sprite pixels per line, even not in the double sized (for avoiding clipping) mode?
A little more than twice, probably because of time spent to set up the coordinate transform. A sprite n pixels wide takes n sprite cycles if not affine or 10 + 2n sprite cycles if affine according to GBATEK.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Another Raycasting Demo

Post by tepples »

"Roguelike Vision Algorithms" by Adam Milazzo describes the RLE ray casting algorithm under the name "shadow casting".
retro65
Posts: 3
Joined: Fri Jul 17, 2020 7:09 am

Re: Another Raycasting Demo

Post by retro65 »

Celius wrote: Sun Dec 28, 2014 8:18 pm Hello everyone!

So about a year and a half ago, I started brewing up this little demo. I started thinking about it when there was discussion in another thread about ray casters on the NES. I just figured, why not release it and show what progress I made, even if I make no more.

I remember being impressed following the threads regarding tokumaru's raycasting project. He was able to accomplish quite a lot; he had textures and did some palette tricks to allow for colored walls, all at a great frame rate. It seemed to me that the biggest draw back was the low horizontal resolution, but palette tricks would be difficult without the 8-pixel wide columns.

So I thought, what if there was a raycaster on the NES that only used one palette for the walls in a room, and didn't have a limited horizontal resolution? Would sacrificing colors for resolution pay off? And with an increased horizontal resolution, it would probably run a little slower. Plus, how would it even work in terms of pattern table/name table updates? So this got me thinking and pretty soon I'm sitting there, building a raycasting engine.

I took a rather different approach to it. The display area is 21x11 tiles, and is constantly filled with tiles $00-$E6. All graphical updates are done to CHR RAM. In order to make this faster, I reduced the resolution to be 84x88 instead of 168x88 (double-wide pixels). Wall textures are limited to 16x16 resolution. Wall texture slices are also defined with code instead of being .db statements. When the ray casting code runs, it draws a frame that looks more like a wire-frame simulation. After that part is drawn, I use a technique called XOR filling to color the entire screen. This makes handling the graphics MUCH easier. In the demo (this isn't in the video), you can press SELECT to see what the walls look like without XOR filling.

I was beginning to work on objects, but then I stopped. I do have the theory all figured out, I just needed to implement it. Essentially, they would behave exactly like walls, but have higher resolution (32x32 instead of 16x16). I would draw them in RAM and sort of "paste" them over the complete background. It would slow things down considerably, though.

There's a lot I could go on about, but I won't bore anyone to tears unless they ask. Feel free to download, and provide comments/questions!

ROM Link:
http://www.freewebs.com/the_bott/Raycast.nes

YouTube Link:
https://www.youtube.com/watch?v=KcOneF-dLfc
Apologize in advance for necroposting, but the ROM link is dead.
This is some good stuff though.
kelvin donna
Posts: 70
Joined: Sat Feb 01, 2020 5:49 am

Re: Another Raycasting Demo

Post by kelvin donna »

tokumaru wrote: Wed Jan 07, 2015 12:07 pm
Celius wrote: There's an interesting Game Boy demo called Back to Earth that has slanted walls and decent texture mapping. Maybe their algorithm is worth checking out.
FYI, this game was supposed to be some kind of FPS for the Gameboy Color, but ended up just as an 3d Engine on the GBC, due to Development Errors, according to the Developers themselves: "This is our 3D shooter. Game was freezed on early stage of development, but we decided to release the engine for download."
QuackCreeper
Posts: 7
Joined: Mon Dec 07, 2020 6:58 am
Contact:

Re: Another Raycasting Demo

Post by QuackCreeper »

This is super impressive
Congrats on this accomplishment!!
User avatar
NovaSquirrel
Posts: 483
Joined: Fri Feb 27, 2009 2:35 pm
Location: Fort Wayne, Indiana
Contact:

Re: Another Raycasting Demo

Post by NovaSquirrel »

Posting the ROM here for preservation (gotten via Wayback Machine)
Attachments
Raycast.nes
(128.02 KiB) Downloaded 34 times
Post Reply