SNES Splatoon (How do I shot HiROM?)

[Drew Sebastino]

Super MMC

What now? I didn't think there was some sort of special chip involved.

even when tepples' sprite scaling scheme is taken into account.

Wait, how? The sprites can't be that big (I imagine about 48x32?) And you don't need that many frames of animation, just turned sprites of the objects, and they can be horizontally flipped for turning in different directions. The only other thing I think you'd need are animations for the vehicle rotating when you press L and R, but that really only needs to be in the head on view. I guess one other thing you could do is have the vehicles flip out before they explode, but that only needs to be a simple animation and you might not even have that anyway, although it's hilarious watching your vehicle bounce around like a pinball and explode, leaving behind a giant raisin.

I'm curious though, but what do you want the SA-1 for anyway? I've always figured you could kind of use mipmapping for objects when they shrink because it takes less CPU time to shrink a smaller object, and it's highly unlikely ever object onscreen is going to appear full size. It's a speed for memory tradeoff. I still imagine this would be smaller than any sort of compression.

One cool thing about prerendered graphics is that once you have the 3D model, it's not all that time-consuming to make more frames of animation from it.

They also already exist: http://128bit.me/index.php?topic=27054. ... #msg192165

Yeah though, I really just need to get my initialization routine working with the change to HiROM, and somehow organize things better, although I'm not entirely sure what I'm doing wrong here, which is a problem. Koitsu, would it even be at all beneficial for me to use the code you edited, or should I just try with what I have?

I should really try to do something like Pong first before I do something as ambitious as this thread's title...

[koitsu]

I should really try to do something like Pong first before I do something as ambitious as this thread's title...

This is probably the best thing I've seen you post in this (or the other gargantuan snesdev thread) so far. Yes, you can and should do exactly that, and you don't need mode 21 for that either.

If you really want proof of what you can do of that fact, go look up some homebrew games like the one called Shoot Your Load (don't let the name fool you into thinking its some pr0n thing, though the title screen does have something funny) -- that's a 4-player (you heard me right) Asteroids-like game for the SNES -- 4mbit (512KByte) ROM, using mode 20, but only about half the ROM is used (i.e. it's more like a 2mbit/256KByte game). It's PAL (meaning 50Hz/50 fps), but it'll run fine on an emulator. Example gameplay video: https://www.youtube.com/watch?v=uXEXLFFMV0M

Mode 21 is absolutely the least of your concerns right now. You have way, WAY bigger fish to worry about.

[93143]

Super MMC

What now? I didn't think there was some sort of special chip involved.

It's part of the SA-1. It maps 8 MB of ROM to 4 MB of address space (more or less - the SA-1 map is the most complicated I've ever seen).

Wait, how?

Multiaxial rotation. With non-flat tracks, I need views from above and maybe even below. Combined with my memory-eating cool trick, just carelessly proliferating desired viewing angles could easily consume over a megabyte for one machine.

I'm curious though, but what do you want the SA-1 for anyway?

Sprite scaling, real-time HDMA table generation for non-flat Mode 7 tracks, map compositing at 4 KB per frame for two-player mode or possibly even more for faking multilayer Mode 7 in single-player mode, software rendering of track past the Mode 7 horizon, software rendering of heavily-fogged terrain below Mode 7 tracks, 3D projection and line drawing for windowing tricks... and of course that cool sprite trick I've been talking about, which is actually very CPU-heavy... not to mention decent A.I. and 3D physics for several racers on screen at once and more offscreen. And most of the graphical elements have to update at 60 fps, otherwise it's not an F-Zero game.

The Super FX is more powerful, but it has a couple of disadvantages:

1) it can only address 2 MB. Anything more has to be installed in parallel, so only the S-CPU can see it. Notice how the above litany of computationally intensive tasks requires access to pretty much all of the game data...

2) it can't share memory with the S-CPU. The SA-1 can generate an HDMA table and then simply leave it in BWRAM for the SNES to use. With the Super FX, the S-CPU would have to DMA it out into WRAM first, or else lock the GSU out of its own RAM, rendering it useless (and unable to update the table). And since DMA and HDMA are incompatible in general on early S-CPUs, this DMA would have to happen during VBlank, restricting bandwidth for other stuff.

Also, the Super Accelerator is sadly underutilized, and it would be neat for it to have a showcase game...

I should really try to do something like Pong first before I do something as ambitious as this thread's title...

I was thinking the same thing. So far I've just been exploring the feasibility of this shmup port, and I've done some neat mockups that stretch the system, but before I start development in earnest I want to have a better idea of how games are put together.

Another member here did a (primitive) game per month for a year; I don't know if I want to get that hardcore about it, but it's certainly the right idea...

[Ramsis]

I should really try to do something like Pong first before I do something as ambitious as this thread's title...

For goodness sake, try to do (i.e., get done) something -- anything! -- before yadayada.

[tepples]

even when tepples' sprite scaling scheme is taken into account.

Wait, how?

The technique is essentially a software version of Neo Geo sprite shrinking. You store a mipmap of sprites at power of 2 sizes (48x32, 24x16, 12x8), and then you use a lookup table to shrink each bitplane of each 8x1 pixel sliver. The table shrinks each bitplane aligned to the right; for the right half of a 16x16, you'd use the multiplier register to shift the shrunken sliver to the left.

[Drew Sebastino]

Another member here did a (primitive) game per month for a year; I don't know if I want to get that hardcore about it, but it's certainly the right idea...

It seems like if you've done one, you've done them all. Well, they'd have to vary in complexity.

This is probably the best thing I've seen you post in this (or the other gargantuan snesdev thread)

Which one? Anyway, I've always had this on my mind, but I never liked the prospect of doing something like Pong that I really can't use as a base for anything else, but seeing that I've already started over before and it's already become hopeless again, I really have no choice.

and you don't need mode 21 for that either.

I wanted to switch over to it so I wouldn't have to change everything latter, but like I said earlier, I'm probably not even going to use anything from it anyway. So yeah, I'll stay with mode 20 for this. The weird thing to me though is that it never seemed like I had to deal with the memory map there (which is why I said I was so oblivious to it). I found the document with the memory maps on it, and I'm downloading it now.

You have way, WAY

WAY,WAY

Actually though, I thought of one thing: Could you upload what you did for me anyway, because I want the batch file then. (Or, you could always just upload that.)

[Drew Sebastino]

Yeah, I got rid of all the fancy stuff I did and cleaned stuff up a bit (the formatting was all over the place) but I can't even get it past the initialization macro at the beginning, in that I put a breakpoint right after it but nothing happened. I pressed step several hundred times and it was all good until it got into a loop for clearing CGRAM. I don't know if it broke there in an infinite loop, but it had to go through this whole thing for 256 colors. I put a breakpoint a few bytes after where the loop was, but it didn't work. The fact that it doesn't output anything for a macros is a bit of a problem... I'm "trying" though.

[koitsu]

No, I won't upload what I currently have (I ran it through diff -ruN and it's somewhat of a mess), but I can clean it up so that it's got as few/minimal changes as possible vs. the original yet still experiences the same bug as before (which has nothing to do with my changes). I'm a little disheartened that despite 3+ pages of text and several people you still aren't exactly sure what to do/fix/change though. :\ On the bright side, you're at least persistent and dedicated.

I'll try to do that tonight or tomorrow and upload the results here. I can't make any promises though; I have stuff I need to do tonight and this week for work.

P.S. -- You can use mode 20 to address up to almost 32mbits/4MBytes of ROM. Board type SHVC-8PV5B supports this; banks $00-7D (126 banks) at 32KBytes ($8000-FFFF) each, means 126 * 32768 = 4,128,768 maximum amount of data (just short of 4MBytes; you lose 2 banks because of banks $7E-7F being RAM). Page 1-2-27 describes this memory model. So ask yourself why you're fooling around with mode 21 especially this early in your learning process. If you really need something larger than 32mbits (up to about 63mbits (just short of 64mbit because of banks $7E-7F)), then mode 25 is your only option, and I absolutely downright refuse to go into any of that given what I've just witnessed in this thread. IMO, respectfully, you have absolutely no reason to be focused on any memory model other than mode 20 right now.

[tepples]

You can use mode 20 to address up to almost 32mbits/4MBytes of ROM. Board type SHVC-8PV5B supports this; banks $00-7D (126 banks) at 32KBytes ($8000-FFFF) each, means 126 * 32768 = 4,128,768 maximum amount of data (just short of 4MBytes; you lose 2 banks because of banks $7E-7F being RAM).

"Almost"? Why can't one just use banks $80-$FF with mode $20 and get the entire 32 Mbit?

[Drew Sebastino]

I'm a little disheartened that despite 3+ pages of text and several people you still aren't exactly sure what to do/fix/change though. :\

Mostly in what to organize.

Actually, screw it though, this is only like 3 actual files so it's not at all hard to figure it out. If anyone has any tips to better organize it, here it is. It's LoROM.

Starting Over, Again....zip

(189.2 KiB) Downloaded 109 times

[koitsu]

You can use mode 20 to address up to almost 32mbits/4MBytes of ROM. Board type SHVC-8PV5B supports this; banks $00-7D (126 banks) at 32KBytes ($8000-FFFF) each, means 126 * 32768 = 4,128,768 maximum amount of data (just short of 4MBytes; you lose 2 banks because of banks $7E-7F being RAM).

"Almost"? Why can't one just use banks $80-$FF with mode $20 and get the entire 32 Mbit?

Yeah, I didn't consider that. Sure, go ahead.

[koitsu]

Here you go. Associated video: https://www.twitch.tv/koitsu/v/61436037 (a little over an hour long)

What I ended up doing was getting rid of all of your .segment nonsense inside of each individual .asm file -- except for Main.asm, which is what effectively says what file should use what segment. As such, you'll see pretty much everything ends up in CODE_UPPER so that the code (effectively) works the same way as it did in mode 20.

One complication stems from use of the RODATA segment (for things like the zero_fill_byte byte used by InitializeSNES). You only had one thing using that, and one thing that "wanted" to use it but was commented out. I stuck those two things in Main.asm's RODATA segment.

I also got rid of the bootstrap routines I made for the vectors, since sticking everything in CODE_UPPER effectively nullifies the need for that (it only matters if you end up needing to run code outside of the upper 32KByte regions of banks $00-3F).

Near the end of the video, I point you Rachel Weil's github repository for a simple little NES (not SNES) thing she made. I point you to this as an example of how to organise code -- you'll find ONE ASM FILE. Your existing SNES project has code scattered throughout __TEN FILES__ (not to mention the whole Objects\Object1 stuff), yet the code really is not "complex enough" to remotely justifying that amount of files. It's mindboggling to me. I've done entire projects where I've used maybe at most 3 .asm files, which assemble tens of thousands of lines of code. If you're going to split things into tons of .asm files, you need to understand how to rely on a better build system and not repeated use of .include statements -- the latter is very KISS principle (and I fully support it!) but it isn't a style that ca65/ld65 caters to (it's a style "linear" assemblers cater to).

Now, all that said:

You have a massive/major/serious/catastrophic problem with some piece of code somewhere within start_object_identifier. This has _nothing_ to do with my changes, and I prove that in the video. As such, I've commented out jsr start_object_identifier within InfiniteLoop, and added this comment:

Code: Select all

; Some code in start_object_identifier (or code called within that)
; is doing something bad with either direct page, the D register, or
; possibly the stack.  Eventually crazy things start happening, such
; as B=$45 and other nonsense.

This is followed by erroneous behaviour that's quite funny to watch in the debugger.

My gut feeling is that you screwing with D (you set D=$0200) causes major issues because other existing code/routines/setup previously expected direct page at $0000. In other words: I believe you're setting D=$0200, and then continue on without putting it back to where it should be. The next time routines run, they read variables/data from direct page, but all those are now wrong (e.g. lda $00 is going to read from $0200 not $0000 like before).

Please don't go blindly adding some lda #$0000, tcd statements to some code until it works. You need to understand what it is you're doing with your own code. Work through it, find the bug, and understand it.

Otherwise you have some code that's stomping all over RAM contents (I peeked at the memory contents at one point -- they become a giant mess, usually filled with a lot of zeros), and it's not my job to figure out why. :-) You're the author!

Good luck -- this is as much as I'm willing to do.

[Drew Sebastino]

Here you go. Associated video: https://www.twitch.tv/koitsu/v/61436037 (a little over an hour long)

I'll be sure to watch it.

I also got rid of the bootstrap routines I made for the vectors, since sticking everything in CODE_UPPER effectively nullifies the need for that (it only matters if you end up needing to run code outside of the upper 32KByte regions of banks $00-3F).

I thought that was basically the point though.

Anyway though, I'll probably come back to this, but I'll try and get Pong in LoROM first. I value your time, even if it doesn't seem like it Even if I don't use the exact files you've given me, I'll (hopefully) have the knowledge to make them.

I point you to this as an example of how to organise code -- you'll find ONE ASM FILE.

Looking at it, it appears that everything code related is in ONE ASM FILE, but all the graphics data and other stuff is in separate files.

Following that concept, I've crammed everything (aside for the header and memory map. I'm not entirely sure how to fix those) into one file. The initialization routine is no longer a macro and is in the code because there's no point in it not being, and the clear vram and clear cgram are separate. I also cleaned other stuff up, as I'm making a big effort now to put everything into my own format.

Main.asm

(12.95 KiB) Downloaded 100 times

By some miracle, it actually appears to work in that some values in ram is affected by the controllers (and ram is all #$00 aside for these registers)

Just one question, is it possible to set something equal to something else (like RButton= 16) in the "Code" segment if it's not in a procedure? All my stuff is currently at the top of the file.

[koitsu]

No -- the point (as I describe in the video) was to get your "stuff" working in mode 21 as easily and with as few changes as possible. I only made one actual "idealistic" change, which was getting rid of all the .segment crap in each file and instead just relied on Main.asm to define it as appropriate.

You can re-visit this problem when 1) you understand the SNES memory map better, and 2) when your program code starts exceeding 2MBytes of (banks $00-3F = 64 banks, upper 32KBytes only available, 64 * 32768 = 2,097,152).

You can still put whatever you want (ex. data) in the lower 32KBytes that's associated with banks $C0-FF, though right now snes.cfg only defines an entry for one of those (lower 32KB in bank $C0); the other banks are essentially undefined. But it's up to you to ensure that you're accessing the data there correctly (using 24-bit addressing, changing B to the appropriate bank, a combo of the two (likely), or using DMA (also likely)).

Equates, or what ca65 calls "numeric constants", can be set anywhere (in any scope -- including globally), but they need to be defined before they can be used. There are examples of such being used in your InitializeController.asm file for some of the SNES memory-mapped registers (those would be within the scope of the CODE_UPPER segment though, given the changes I made to Main.asm).

With a "linear assembler", all this segment and scope crap doesn't really matter -- it's all "programmers masturbation material". All that really matters is 1) if what ends up in the ROM file is correct (meaning it does what intended/assembled to the correct instructions), and 2) that the code was written with knowledge of what the memory map (mode 20, 21, etc.) was. Seriously. I've said this before, but I spend more time "fighting" with ca65/ld65 than I do actually writing code -- in olden days, it was the exact opposite.

P.S. -- Please do not use that avatar; I thought you were rainwarrior for a moment. I can assure you that you will get banned pulling shit like that. This site has a very simple rule: don't be a dick (Wheaton's Law). The logic is pretty simple: "if you don't know what that encompasses or means, then you're probably being a dick".

[Drew Sebastino]

I can assure you that you will get banned pulling shit like that.

Yeah, I don't feel like getting banned, so it's gone.