I want to make a demake of Wolfenstien 3d on the NES using CHR RAM. But I don't quite understand how the Ray Casting system works. How does it know what pattern of pixels to make? You probably have no idea what I'm talking about. What I'm trying to say is when you are looking at a cube from an angle, you have to have their be a slant in the edges to make it look 3-dimensional. How does it know what pattern to make? It doesn't have a physical camera, so I'm confused. I've never done anything related to rendering 3D.

I can give you a quick rundown on how raycasting works, but implementing it on the NES (at playable speeds) will require a lot of cleverness and optimization of the basic technique. How good are you with trigonometry? Raycasting basically involves a lot of triangles whose sides and hypotenuses you have to find.

I can give you a quick rundown on how raycasting works, but implementing it on the NES (at playable speeds) will require a lot of cleverness and optimization of the basic technique. How good are you with trigonometry? Raycasting basically involves a lot of triangles whose sides and hypotenuses you have to find.

I don't know anything about Trigonometry, I'm only in middle school. I'll try learning it on my own, though.

Then I simply can't explain how raycasting works in detail, since I'd have to teach you trigonometry as well. You need to at least understand what sines, cosines and tangents are, how they relate to the unit circle and their basic formulas.

I can still give you a basic overview of how things work, though. Like I said, raycasting is all about triangles:

To draw a scene, you have to cast several rays away from the player at successive angles. When you cast a ray from player P at angle A, it hits a wall W at point X, forming a triangle. You need to apply trigonometric formulas to find the distance from the player to the wall (HYP), and use that information to calculate how tall that wall slice will appear on screen (greater distances result in smaller walls). Then you also need to find the opposite side (OPP), so you know the exact coordinate that was hit by the ray, in order to know what texture slice to use. Then you just need to do the actual scaling of the texture.

This is a very basic overview of the process, since each of these processes has to be broken down into smaller tasks. Casting the ray for example involves the use of smaller triangles, aligned to the grid:

The formulas necessary to do this have a lot of divisions and multiplications, things the 6502 is just not good at, so you'll need to be clever and find ways to optimize those as much as possible. In my engine I was able to turn all divisions into multiplications or table look-ups, and I significantly reduced the number of multiplications by combining multiple operations into a single step.

It's true, you do seem a little ambitious for someone who's so young and is just starting out with NES development. I'm an example of someone who has learned a lot of stuff over the years without releasing anything, but I wouldn't recommend that to anyone... I'd rather have released some simpler games! Try to set a simpler goal (not pong though, please, we have enough of those!) and go through with it.

It's true, you do seem a little ambitious for someone who's so young and is just starting out with NES development.

12?!? I thought me being 15 when I signed up here was bad!

Yeah though, I hate to be the bearer of bad news, but starting out programming by building a raycasting engine (which I have no clue how to do!) will only lead to frustration. I don't think this is something you can really cut into steps where you can see your progress, unlike with a traditional 2D engine.

Just because you probably shouldn't do this doesn't mean you shouldn't avoid the NES. My first programming experience was actually with the SNES, although I didn't understand memory modes for more than my whole first year... I can't say for sure, but I heard learning higher level programming languages will not help you very much for learning assembly, because they are completely different. I know anything other than assembly or machine code still looks like gibberish to me.

I mean yeah, That does seem kind of complicated and hard to do, but I don't mean to brag, but I've learned Java when I was 7. I could probably learn a lot doing this, But to keep it simple, I'll start with a ray-casting engine in C++. I don't see any harm in at least trying.

I mean yeah, That does seem kind of complicated and hard to do, but I don't mean to brag, but I've learned Java when I was 7. I could probably learn a lot doing this, But to keep it simple, I'll start with a ray-casting engine in C++. I don't see any harm in at least trying.

I wrote my first game when I was 7. It was a silly little text-mode BASIC thing - no Java in those days! - but it had two players, an AI and win/loss conditions.

I wrote my second game when I was 23 and a half. I spent the intervening time doing exactly what you're doing - aiming for the stars and falling short of the clouds. I'm trying not to sound judgemental, and if that's what you want to do then by all means go for it - but if you want to make games now, you're on the wrong trajectory. Trust me, I've been there.

My advice: whip up something easy, say a roguelike. Doesn't matter if it's awful, doesn't matter if nobody else ever sees it, doesn't matter if you throw the whole thing out and start over. You can learn much, much faster by doing than by reading, and nothing I've tried quite lives up to playing your own game, thinking "wouldn't it be cool if...", and two hours of furious coding and testing later, having found and implemented something even better.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum