So what kind of stuff do people want to see on the SNES?

I proposed the idea of making an engine that acts like the SNES has a large CHR-ROM based sprite system in another thread, to make sprite animation easier for other programmers. I didn't know if people just didn't notice it, or weren't interested, or didn't understand what it is.

So I'm going to ask, if people are not interested in this, what types of stuff do people want to see happen next? If we still want to create a generic game engine for beginners, does anybody want to include some built in special effects, such as HDMA line scrolling effects? In the near future I might be able to do almost real-time sprite scaling and rotation on multiple sprites at once, just as long as I have plenty of SRAM to use. It might be a fun little cheat for beginners who might be unimpressed with static sprites.

I read most of the code you write, but I don't understand alot of it.

You mentioned "beginners". If you want to help beginners, you need to explain things very very basic. Like...here's a step by step to go from a GIMP image, to create a CHR file. Here's how to load it to VRAM. Here's how to put it on screen. Here's how to animate it. Lots of details.

The code I posted this morning I don't think is that bad.

The thing is there's already lots of tutorials on ASM and PPU. A lot of people complain about the lack of example codes. The example codes I post aren't supposed to "teach" ASM, they're just there as a high level abstraction.

Languages like C and C++ use mysterious functions, and nobody cares how those functions work.

That last comment.

What I would include in a game engine, is an object table (obviously), a system for adding and deleting objects, a system for actually running object code, a system for creating metasprites (with flipping and no size or shape limitations; just add or subtract x/y values) an animation engine, (it offsets a table with the offsets for metasprite data and tile data; can loop or end) and a dynamic VRAM engine (16x16 and 32x32 sized sprites are fitted into sprite VRAM wherever possible, making sure there are no redundant graphics to save space). Palettes for sprites would be fitted into CGRAM dynamically as well. (My system of changing palettes midscreen is probably overkill, and takes Hblank time...) A CGRAM and a VRAM uploader would need to be made. (The VRAM uploader would probably have separate routines for 8x8 tile/tilemap uploads and sprite tile uploads, as the latter can be more hardcoded.)

I don't really have much of an opinion on what should be included for backgrounds, because I feel like it varies too much from game to game to have an all-purpose solution. Some games need to deal with scrolling freely, while others only need to scroll on one axis at a time, and often only in one direction, and still others don't need to scroll at all. Games that can scroll more linearly can have new tiles uploaded as the screen scrolls, whereas I really don't know how you'd do this with scrolling freely. I think a system that decides when objects are spawned or destroyed should also be up to the programmer to make; some games need to process things offscreen while others don't; some games don't even need to keep track of what has been destroyed if they only scroll forward. I thing both sprite collision and background collision can also be done by the programmer. Fighting games, for example, don't need background collision beyond one "if less/greater than".

Basically, anything that actually touches hardware registers needs to be included. Anything that deals with hardware limitations (128 sprites, 16KB sprite VRAM, 8 sprite palettes) should also be included, although a programmer using the engine should obviously still be cognizant of these limitations even if they don't have to worry about them as much. Things that don't deal with video hardware and are thus no different to program for than on any other system (collision detection, physics, object creation/destruction) don't need to be included.

I vote for 3., I don't understand what this is.

Even in the best case, interest in such a SNES game engine will be low. Look at comparable engines targeting other platforms, they barely have one user each.

To gain interest from modders, your engine will probably need to be as complete as that of Super Mario World, as will its sample block and sprite graphics.

My engine already does everything Espozo's first paragraph mentions except for dynamic sprite and CGRAM allocation. I am actually halfway to the former, because I have updated my sprite placement function so that objects can override the tile and attribute bytes of OAM and therefore offset themselves to use the sprite slot they were assigned.

The World system that I'm planning for later will be in an optional module that is invoked by scene specific code so only games that need it will be using it.

Edit: I also don't have metasprite flipping because I'd rather have flipped versions as separate definitions for performance.

So I'm referring to the code on this page:
viewtopic.php?f=12&t=10957&start=285

I made a diagram to explain what it does.

I actually don't either for the same reason. I figured people would be put off by a lack of flipping, but really, if we wanted anyone to adopt a game engine like this, we would have to make a tool for building metasprites anyway, in which case you could implement a feature where a mirrored duplicates can automatically be made. It will take more ROM space, but I and more than likely others could give a shit.

@Psychopathicteen Why would you need SRAM for this? I wonder how much faster this would be than the system I have. (Which still isn't finished...) It doesn't look like it would offer any advantage other than speed, because of how 16x16 and 32x32 sized sprites have to be separated. I guess if there are two different objects with some sprites in common, it would save space over my system that only checks whether an entire object's graphics are in common rather than their individual sprites.

Without using an extremely long table, it would have to compare 128 sprites to 32 slots.

Didn't somebody post a code for writing every sPPU register in vblank a while? That would also be useful for a generic engine.

Found it
viewtopic.php?f=12&t=14457

I decided to make my own shadow sPPU update code, for general use. I discovered a new trick with write-twice registers, where you just need to make a 16-bit write to the high bytes of the register, and it would automatically write the low byte of the next register in one go. The might be an even faster way with PEI, but I'm not sure the exact behavior of writing these registers out of order.

For mode 7 settings for example, why don't use MVN ??

They're write twice registers, so I have to do overlapping 16-bit writes.

I would like to see a Game Boy Color cart/game using VIN expansion audio to be plugged into a Super Game Boy 2, also utilizing the SPC700 audio to full extent and somehow using the SGB border as an active element of gameplay.

I'd like to the SNES push a 160x144, 15bpp framebuffer every frame too.

Okay, you could try and have the SNES emulate GBC video rather than copying a framebuffer off of the cartridge, But there are many hiccups you would run into, like 4bpp instead of 2bpp sprites, and 2bpp BG layer palettes all using color 0, which means you'd have to use 4bpp graphics for BG layers too. I guess you could deal with this if the SNES can upload 2x as much graphical data into VRAM in one frame.

The Super Game Boy 2 was never released for the Super Nintendo Entertainment System. It was exclusive to the Super Famicom; use with the NTSC Super NES requires modification of the console's Game Pak slot, and I doubt it works with the PAL Super NES at all.

Espozo: I think the Super Game Boy 2, specifically 2, was mentioned because 2 added a Game Link port. The idea is that the GBC and SGB2 would be connected through Game Link, running a GBC-mode master program on the GBC and a monochrome slave program on the SGB2 that uses the SPC700.

An SNES engine should allow the ability to switch between Mode-7 and normal modes mid level, so I'm thinking about arranging VRAM like this:



...and a way to sweep VRAM while transitioning between parts of the level.

I should really work on this new engine thing. I've been putting this off just because initialization routines are boring, especially when you're setting up registers in VBLANK that you don't need until much later.

I made a table of where I'll put all the shadow sPPU registers in WRAM.



These work with this code: