|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
![]() |
Author | Message |
---|---|
|
S.A.M. - Simple Adventure Maker
![]() |
This is a little program for making simple adventure games for the Sega Master System. It has a simple built-in script language for text, menus and game logic, and supports the displaying of static images along with the text.
For a quick start, simply unzip the file, go to the "example" folder, and double-click the batch file named "Compile". It will compile the example demonstration. Documentation, sound and image compression support should come on the next version, along with support for multiple scripts. |
|
![]() ![]() ![]() |
|
|
![]() |
That is great! :-)
Sweet! - Really looking forward to the next version already ! |
|
![]() ![]() ![]() |
|
|
![]() |
Given what happened with the SG-1000 Fudebrowser, I take it we can expect some porn slideshow "adventures" soon? | |
![]() ![]() ![]() |
|
|
![]() |
Thanks, I'll try my best! :-)
Well... as long as people are having fun... XD |
|
![]() ![]() ![]() |
|
|
![]() |
Okay, people, here's a new version, now with support for multiple scripts, subroutines and music. There's some very preliminary documentation, too.
Compression should come on next version, as well as improved documentation. |
|
![]() ![]() ![]() |
|
|
![]() |
Wouldn't it be more efficient to have the script parsing done on the PC instead of the SMS? I imagine error handling would be more robust there, and the SMS code would be a lot simpler.
Also, your work to convert a .inc file to a binary one seems a lot of work considering that BMP2Tile can output binary files directly. |
|
![]() ![]() ![]() |
|
|
![]() |
Actually, not so much. If you take a look at the interpreter code you'll see that, due to the way the language is structured, the parsing is pretty minimal (Every instruction, except numbers, is a single char), and the scripts occupy very little space. In fact, the word-wrapping code alone is much more complex than the whole interpreter. Besides, it was fun to write. =P
Actually, there's no .inc to .bin involved, the SimResBuilder and ResTableBuilder are there to just to build pointer tables. Anyway, thanks for pointing out that BMP2Tile has .bin support. That will simplify the implementation of compression support. |
|
![]() ![]() ![]() |
|
|
![]() |
Here's the new version, now with support for compressed tilesets.
Originally, I was intending to use aPack compression but, since it was causing random corruption on screen (even with interrupts disabled), I ended up using the Phantasy Star RLE compression, like the one that BMP2Tile supports. Well, now that it's mostly working, all that is left to do is writing a better manual and creating a proper example game. |
|
![]() ![]() ![]() |
|
|
![]() |
It's possible the aPack decoder is broken - I only ported it, without particularly understanding it, and I didn't exercise the direct-to-VRAM part very much. Using RLE probably makes more sense anyway since it's much faster.
Can you send me some example files that demonstrate the problem? Why not make your example project build the graphics from source .PNG files or similar, rather than supply pre-produced tile/tilemap/palette files? BMP2Tile is happy to run from a batch file or even a makefile. You're welcome to distribute bmp2tile as part of your package. Speaking of which, distributing WLA DX requires you to include the GPL LICENSE file. |
|
![]() ![]() ![]() |
|
|
![]() |
Yes, you're right, I also think RLE will be enough (besides, at least on the tilesets used, the compression difference isn't that big). Anyway,I've sent the test to your e-mail, maybe it will be useful for something... or not. =)
I gotta read those readmes more often... It's a pretty good idea, it's easy to do and will make the toolset much easier to use. In fact, here's the new version. =)
Whoops... okay, solved. |
|
![]() ![]() ![]() |
|
|
![]() |
Bad news: I had a bug in my code. So for certain bytes it would write them to ROM instead of VRAM... Good news: the fix actually saves 2 bytes from the decompressor. Update is here: http://www.smspower.org/maxim/smssoftware/aplib.html Tested with your demo, I had to add di/ei around calls to the decompressor and then it works perfectly. It might be interesting to reengineer the aplib support to work with interleaved data, as the RLE compressor does. It should yield a compression boost in many cases, although it is dependent on the palette ordering. So, of course, it might be interesting to brute-force the palette order too... |
|
![]() ![]() ![]() |
|
|
![]() |
Thanks! =) Maybe I could add aPack as an alternate compression scheme on S.A.M. Anyone interested?
I see what you mean. By separating the color planes, tile data would become potentially more "repeatable", therefore improving compression.
XD |
|
![]() ![]() ![]() |
![]() |