Thanks!UnDisbeliever wrote:This is awesome, we need more SNES homebrew code in the wild.
I've read through the code and understand how the engine works. I love the simplicity of this engine (unlike mine which is a little all over the place). I hope you keep it up as the engine expands.
I'm a big fan of line breaks to visibly separate portions of code so this is on my todo list.I did have a bit of trouble recognising the start of a routine due to the lack of spacing. Would it be possible to add a second blank line in-between the routines to improve readability?
That's a good idea. I'll try to be more explicit about referring to function pointers. It's one of those gotchas I noticed while I was trying out the feasibility of doing HiROM program bank with LoROM data bank.You need to expand the Memory Bank Details section.
The code bank table is a little confusing. I do not believe a beginner to the 65816 would read it and realise that they cannot jsr addr or jmp addr from the hi bank to the lo bank.
Honestly, I'm not sure how to properly explain it myself, but I think adding these two rows to the table would help:The phrase "Indirect addressing via RAM is not available when running code in Code 0 Lo or Code 1 Lo" is also confusing. I initially though you were talking about direct page indirect address but after scratching my head for a few minutes realised you were talking about function pointers.Code: Select all
jsr addr, jmp addr | code0lo, code0hi | code0hi | code1lo, code1hi | code1lo access function pointers in RAM | NO | YES | NO | YES
When I designed the object pool system, my intention was that a given type of object would only ever be used in one specific pool and that DeleteObject would be called by the object itself. But since CreateObject is pretty fast, I could probably afford to do some record keeping there so the user doesn't have to.I do not like the fact I have to pass the object pool index to DeleteObject. This prevents me from writing a routine for deleting objects when they go outside the active window and reusing it across different pools (unless I store the pool in the object, which complicates the object's init routine).
I had also envisioned the objects themselves taking care of the out-of-screen logic, since AddSprite does a preliminary range check of its own. If the function exits with the overflow bit set, you can delete the object right there, or do a more precise check (since the range used by AddSprite is a bit... asymmetric). This is the technique used in the Bounceballs example.