Sonic and Sega Retro Message Board: Kroc - Viewing Profile - Sonic and Sega Retro Message Board

If we swap the raw CDDA data in the CD-image and adjust the CUE sheet accordingly, then it should work as the EBOOT converter doesn't actually decode or play the CDDA tracks, it just copies them as-is, ignorantly.

It's sad that there's no PSP development going on anymore. Every /vr/ thread that crops up about which is the best emulation device always ends with the PSP. It's cheap, easily modded and has actual controls you'd want to use. I love my PSP, but I'm not a C coder and can't do anything about the situation.

Yes, but with scrolling!?? My first was something like 20'000 image controls on one form, moving every one for every scroll!
Nowadays I API render just the necessary portions. If you're still using VB6 then check out the source code for MaSS1VE, there's plenty of cool technology there.

I've been writing editors since 1999. My first was awful. It used an array of image controls, one for each tile, the size of the grid and repositioned the *thousands* of controls every scroll. It was slooow. But -- it worked. And that's the point.

Even if you have no knowledge of editors, go ahead and try. You'll learn a lot just by trying. You'll have to rewrite many times, getting better each time, you'll learn by doing. You can't be perfect on first try, don't ever try so hard to be right the first time that you never get anything finished.

It's far, far better to make something that's crappy but works out there than to have your perfect pet project remain in obscurity for ever.

Sometimes you don't know what you need to do until you try doing it. This is my advice to you.

Quote

There are limitations in WLA DX that would prevent that from solving some problems -- I'll just copy in the reply I made on the SMSPower thread where this is also being discussed.

---

I'll give you an example where WLA DX is slipping up and where a preprocessor really won't help --

I need to calculate offsets from the start of a bank to the data, but in a portable way since I will be providing 256K and 512K ROM layouts.

You can't calculate using a bank number, nor can you pass it as a macro parameter.

_label:
.PRINTV HEX :_label ;this does not work

A preprocessor cannot solve this as it cannot tell what bank a symbol may lie in.

Here's another example of something that really badly needs fixing:

Bank boundaries are a pain to manage. For example, the block mappings in Sonic 1 extend from $10'000 to $15'580, across the bank boundary at $14'000. If I (or anybody) wants to modify that data, they have to manually move the .BANK statement precisely byte-for-byte.

I propose the ability to allow data to not overflow bank boundaries when specified in this manner:

.BANK 3, 4 ;or, also like
.BANK 0-2

This way I can have data that crosses the bank boundary without having to manage the exact byte split.

---

Quote

Yes, and also no-no-no I've got some macros that largely implement the table syntax, but I'm running up against WLA DX bugs and outright holes in functionality that cannot be macro'd or preprocessored around.

I appreciate all the words and feedback. I'm rolling everything around in my head and working out the best strategy.

Thank you for pointing me to that @flamewing. I've discovered many more bugs and limitations of WLA DX that I don't think would be solvable any time soon and whilst AS is nice I feel it suffers from the same design problems with WLA DX that I'm looking to overcome.

To that end I'm formulating a spec for a new ASM script language, here's a very rough draft to show what I'm getting at:
https://gist.github.com/Kroc/7940880