I know /vr/ is a place where clever anons exist, so I'd like to ask a question.
I'd want to make an SNES Mode 7 demo where you could raise/lower the horizon, turn around and change the scale. But I have no clue how to program in assembler.
What do?
>>3365283
>/vr/
>clever
well first you obviously learn assembly, retard
>>3365283
Well you should start by looking up this
https://en.wikibooks.org/wiki/Super_NES_Programming
But if you don't even know the basics of assembly you won't get far. Good news is that the 65816 a well documented microprocessor with many tutorials same with general SNES programing.
Good luck, op
Your first mistake is in thinking that learning 65c816 assembly is the hard part. Assembly of any kind is generally pretty straight forward. z80 assembly for the GB is downright trivial. The difficulty in working at this level isn't the language, it's the hardware. You have to learn how the memory mapping for the system is laid out, how to interact with specific hardware components, the rituals required to make the hardware actually function, the correct formatting of raw binary data for use with specific hardware components, lots and lots of shit. Get your hands on a leaked copy of the official dev booklet and memorize it.
>>3365283
>What do?
Learn how to code in assembler.
>>3365283
Write it in another language first. Hell you could just take a piece of graphic (a random image file) and write a program that applies the scaling/rotation you want to it, on a line-by-line basis, as that is how the snes does mode 7: does rotation/scaling, then changes the values on every scanline. Then set it up so you can change the required coordinates fast and efficient and in a way that your code predictably does what you need it to do.
The actual arithmetic for what you want to do may be more difficult than learning SNES assembly.
Once you have the math behind what you want, the coding part is literally just punching in the same numbers and the controller interaction (and loading the gfx into vram). I mean most assembly commands are things like "move x to address y", "add a+b, store result in register c", and so on. Punching in numbers in the correct order.
>>3365756
>Write it in another language first
easier said than done. mode 7 code on the SNES does very little. The majority of the output is the PPU. If you were to code it in another language you'd have to implement all of that PPU stuff too. Learning asm, familiarizing yourself with the SNES, and then doing things step by step (bg output, mode 7, rotated bg output, hdma effect, mode 7 + hdma) is the way to go
>>3365292
This. It's not that hard if you can program at all. It's been about 17 years since I did it in uni, don't get me wrong, but I picked it up really quickly and I'm sure I could again if I needed to.
>>3366854
>The majority of the output is the PPU
You're not giving programmers enough credit here. Yeah, an affine transform is done by the PPU, but that's one equation of math. To use Mode7 like how OP wants to, he needs to use HDMA to change the Mode7 parameters per scanline. Thus he needs a program that generates those parameters, and that's a lot more complicated than the affine transform. If you disagree, post your solution. Also, you can be creative with the parameters and do tricks with the map like how Terranigma fakes curvature. To get fancy, you'd want to calculate fogging too and apply a constant color addition, once again modulated by HDMA.
At the end of the day you have only 6 numbers to edit (2x2 matrix parameters and 2x1 translation parameters), but it can be tricky.
>>3367197
You need a program to generate these parameters, indeed. That's first and foremost math. You end up with an array of 100-something structs and that's it. You will not produce any meaningful output with that on any system except the SNES. That was my point.
To write it in another language you'd need upfront an engine that performs a tile lookup, the affine transform, fills a framebuffer. Then you need to add the hblank hook, in order to change the affine transform parameters on the fly. At that point you've written close to a PPU emulator
>At the end of the day you have only 6 numbers to edit (2x2 matrix parameters and 2x1 translation parameters), but it can be tricky.
Precisely. The actual code for the effect is largely concerned with manipulating a handful of registers. You can implement that in another language, but you won't see shit. You'd need a thorough understanding of mode 7 and hdma to read these numbers. If you have that understanding, you already know the asm and can do it directly for the real hardware.
>You're not giving programmers enough credit here
fuck off, shithead. Fucking hate assuming idiots like you. Go suck on the business end of a gun, get a noose necklace, whatever. Just make sure you won't waste any more air or space on this planet.
>>3367208
Holy shit, hot post there, fuck face. Way to say a whole lot of nothing.
>The actual code for the effect is largely concerned with manipulating a handful of registers.
Congratulations, you have correctly identified that you need to write to PPU registers to manipulate PPU images.
But you know what? All SNES devs know that. The thing that separates good devs from bad devs though are skills to develop code that produces a better stream of numbers to feed the PPU.
You know, the first and foremost mathy bit?
>To write it in another language you'd need upfront an engine ...and some more garbage ...
Producing numbers for Mode7 and drawing Mode7 are completely disjoint problems. You can write a world map program in C without having the means to display it, it just wouldn't be easy to debug.
>You'd need a thorough understanding of mode 7 and hdma to read these numbers
I didn't realize SNES Mode7 was a prerequisite to linear algebra.
>>3367389
now you tell me how all your hot air relates to >>3366854
>Producing numbers for Mode7 and drawing Mode7 are completely disjoint problems
Not when someone suggests you
>Write it in another language first
even clarifying with
>Hell you could just take a piece of graphic (a random image file) and write a program that applies the scaling/rotation
that yes, they do mean the whole output routine, not just producing the transform matrix
>I didn't realize SNES Mode7 was a prerequisite to linear algebra.
understanding mode 7 is important to understand why you want to produce numbers following that particular linear algebra
>>3367208
>You will not produce any meaningful output with that on any system except the SNES. That was my point.
What the SNES does there is set up a background with a given affine matrix, then changes the affine matrix every scanline. You could easily come up with a routine that takes your input graphic and iterates through every line of it, same way how the SNES draws each scanline.
>performs a tile lookup
You can worry about that once you are punching numbers into the SNES
>the affine transform
This is the meat of the math you need to calculate for your mode 7, that you can do in advance in another language.
>fills a framebuffer
Literally just copying data line by line to an output buffer.
>Then you need to add the hblank hook
Set up a loop that iterates through your graphic file line by line, does an affine transform on the line, then copies the result into the output (aka the "framebuffer").
Yes, you are basically doing a software rasterizer this way. But the whole point of doing this is so you have all of this in advance, so you don't have to figure out your affine transform math AND 65816 assembly at the same time. No, you first figure out what math you want, then you figure out how to do that on the SNES. Take things one at a time, not everything at once. Once you have your transform math, you can worry about setting up your gfx tiles on the SNES, then converting your loop to be based on continuous hblank interrupts instead.
>>3367454
>You could easily come up with a routine that takes your input graphic and iterates through every line of it
sure, but you'd have to write it first. Write code that will not exist on the SNES, because on the SNES the PPU does the work.
>You can worry about that once you are punching numbers into the SNES
It's kind of necessary to produce the output on another platform. Even if you use a generic texture, you still need to look up the correct texel, something the SNES does on its own
>Literally just copying data line by line to an output buffer.
"line by line" won't do you much, as you need to apply the affine transform. Something the SNES does on its own
>you are basically doing a software rasterizer this way
been my point since post one, which you've been oh so angrily argueing against because you need something to be outraged about
>so you have all of this in advance
90% of that code will not exist on the SNES variant
>have to figure out your affine transform math
You have to do that either way. That's done via pen & paper.
>AND 65816 assembly
It's fairly simple (like all assembler of the time). Translating your pen & paper math into it is an exercise, not more
>No, you first figure out what math you want
paper
>then you figure out how to do that on the SNES
SNES
notice the lack of another platform in between?
>Take things one at a time, not everything at once
It's almost like I wrote that shit in the post you're attacking. Let me check ... >>3366854
>Learning asm, familiarizing yourself with the SNES, and then doing things step by step
Yup, I wrote exactly that.
>figure out how to do that on the SNES. Take things one at a time, not everything at once. Once
wrong way round. First you produce output, then you alter it. The output is your debugging feedback
>>3367454
I botched the last quote in >>3367467
so once more with feeling
>Once you have your transform math, you can worry about setting up your gfx tiles on the SNES
wrong way round. First you produce output, then you alter it. The output is your debugging feedback
Though regarding the math, there's no first or then, as the math is completely independent from the platform. That's something you don't need the SNES or any other code for, though it helps to understand what the SNES is doing. You can gain a lot of that understanding by working with the system. I kind of outlined that in >>3366854
>bg output, mode 7, rotated bg output, hdma effect, mode 7 + hdma
The first two steps help understand the SNES on a conceptual level, third step introduces the affine transform. Fourth step is a bit of a sidequest, to understand the concept of HDMA, which you don't want to do while trying to figure out the math. Last step is putting it all together. I did not mention the math during these steps, because it's kind of independent from all of it. Though I suppose a good point for it would be sometime during or after the third step, when the affine transform is introduced
>>3367476
>wrong way round. First you produce output, then you alter it. The output is your debugging feedback
Obviously, but to apply an affine transform to a piece of bitmap, you don't need a SNES for that. And you can easily simulate how the SNES does it.
>I did not mention the math during these steps, because it's kind of independent from all of it.
That's *exactly* what I'm saying. First figure out your math - you can do that on a higher level language. Then you can work on implementing it on a SNES.
>>3367514
>you don't need a SNES for that
just a render engine providing all the infrastructure.
>you can easily simulate how the SNES does it
happen to have such an engine lying around? If not, you're suggesting someone curious about the SNES is writig one, from scratch. I have an alternative suggestion: Use one. Every single SNES emulator has a pretty capable Mode 7 rendering engine included
>First figure out your math
If you don't know what math, or why, that's a bit futile
>you can do that on a higher level language
you can do that on a piece of paper. The math is not hard. It's just not obvious
>Then you can work on implementing it on a SNES
and skip all the extra work of implementing an engine (which requires a shitload of knowledge that's completely worthless for SNES coding)
>>3367518
okay I think now you are just arguing for the sake of sounding smart, because you are not giving any thought to any of your questions.
>just a render engine providing all the infrastructure.
>happen to have such an engine lying around?
Take a bitmap, set up a loop that iterates through every line, and copies it out to an output. Before that copy happens, apply your affine transform to the given line. There you go: now you have a rendering engine that simulates mode 7 3d ground, without touching a single piece of 65816 snes assembly. The reason I recommend this is because this way you can see the exact input and output which makes a heck of a difference when using math to do visual effects, plus you won't have to worry if it is your math being wrong or if it is your 65816 assembly that is wrong (because you are not doing assembly).
You can even set up your affine transform to work with the same transformation matrix that the SNES PPU takes as input.
After that just mess with the inputs so you can take "go up 10 pixel" or " go left 10 pixel" to change the orientation of your graphics (ie. hook up "controls" so they are turned into the transformation matrix you need). Now you have a basic engine to use!
>and skip all the extra work of implementing an engine (which requires a shitload of knowledge that's completely worthless for SNES coding)
OP doesn't want an engine, he just wants to set up a mode 7 ground that you can move/turn/tilt around. That requires you to figure out the matrix transform for a background, how to change it via HDMA (eg. changing your matrix every line), and hooking up the controller to move your perspective around.
Yes, you can first learn how to do a+b on the SNES, but that's literally a chicken & the egg argument. You can either learn how to do SNES assembly then learn how to do affine transform on it, or you can learn how to do affine transform and then punch it into the SNES. It doesn't matter which you do first.
>>3367643
>Take a bitmap, set up a loop that iterates through every line, and copies it out to an output. Before that copy happens, apply your affine transform to the given line
and absolutely none of it is necessary when dealing with the SNES
>this way you can see the exact input and output
just like on the SNES
>if it is your math being wrong or if it is your 65816 assembly that is wrong
that's the same thing
>just mess with the inputs
the inputs of that other language, you're suddenly dealing with all kind of shit that's completely irrelevant for the SNES
>That requires you to figure out the matrix transform for a background, how to change it via HDMA (eg. changing your matrix every line), and hooking up the controller to move your perspective around.
all things that are very different between the SNES and a high level mockup, unless you go all the way and actually set up the high level mockup with input abstractions, hblank and vblank.
>It doesn't matter which you do first.
and that's the reason you shit on me for half a dozen posts? Seriously, go off yourself. You're a piece of shit
