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.

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.

_________________nesdoug.com -- blog/tutorial on programming for the NES

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.

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 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.

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.

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

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.

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.

Who is online

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