The SNES can't rotate tiles like that. Only X and Y flipping is possible. The best you would get is a feature that rotates a map16 tile and generates four new 8x8 tiles that are pre-rotated but that needs extra GFX space unlike X/Y flips. It wouldn't be any different than if you just manually roated the tiles yourself.

I had a look at look at emulator source and some cart docs a while back and it looks like 708000/F08000 etc. are safe to use for ROM in any modern emulator.

bsnes from a while ago:



snes9x 1.53:



Older/smaller games without MAD-1 on the cart put SRAM at 708000+ but MAD-1 games don't. The newer/bigger games work fine when reading ROM from those areas. A ROM that is big enough to require the 708000+/F08000+ area should have no problem using it. I tried a SMWCP2 ROM which is 4MB lorom and ROM shows up at 708000/F08000 like it should in bsnes 080 memory viewer.

If you are new to programming, I'd go with the least painful way of getting familiar with the concepts before worrying about efficiency. Python is a great first language with far less potential stumbling blocks compared to most others, especially C++. You're going to make a ton of mistakes early on so it's better to start with a language that minimises the amount of cryptic bullshit you have to deal with. Python is great for that. It's a bad idea to worry about 2) this early on. It's not the most efficient but once you get the concepts down, jumping to another language isn't so hard if you find it's too slow for your needs.

I use C++(11) and C# mostly depending on the app requirements and I usually go with the latter. I wouldn't recommend either as a first language though. If you do have interest in Java, I suggest you atleast have a look at C# first unless you know well in advance that it won't work on the platforms you'd want to use. That's C#'s big weakness but Java as a programming language is awful by comparison, even with fundamental stuff. There's so many things it's either lacking in or has awful implementations of. You won't have that much trouble learning one after you've learned the other though.

edit: just realised this should be in programming instead. I'll move it over.

There's a bug that I caught a while ago that can cause a crash if rare requirements are met. It's fixed and ready for the next BT but I might either patch it if ends up taking a while. PM me the ROM with your steps followed that causes this crash and I'll confirm the issue.

The asl $4216 is enough of a delay but that's a dangerous way to do it. What are the next few lines of code? You could probably remove any delay stalling by reorganising it.



You have the DB set to 7E here which means you're reading/writing RAM instead of the hardware. It's easy to get caught by that when using 16bit addressing if you forget what the DB currently is.

I forgot all about adding coprocessors to SMW. We had SMW+superfx/sa-1 demos a long time ago but they never caught on for various reasons that aren't really issues anymore. If it does catch on this time, SA-1 is definitely the way to go. There's plenty of documentation, it's easy to use and it's the most flexible.

Some other nice-to-have things might be fast decompression/level building to cut load times. There's also the idea of vblank speedups by getting the sa-1 to generate the fastest possible code each frame by sharing any needed data with it, then just having the SNES jump to the code in RAM within NMI. It would mostly consist of a long stream of immediate loads and stores to DMA registers with direct page used for space/speed benefit. That can help raise the exanimation ceiling a fair bit.

Are you doing all that math for every pixel or has it been optimised arleady? It should be very fast at 10MHz with code that calculates start position once and then just adds deltax/deltay to the source pixel position.



It would work a lot better if the level data was on cart RAM but there's still plenty of potential speedup. There's a few ideas I have to make it run better if SA-1 ever gets popular. There's also another idea that can be done with just the SNES (but SA-1 assistance would also help) that might appear in later versions if Fusoya agrees to updating it.