Emuze

Topics on software tools like TileStudio, comments on documentation and tutorials (or the lack of) should go here.
User avatar
paul
Posts: 457
Joined: Sat May 02, 2009 8:41 am
Location: Brisbane, Australia

Re: Emuze

Post by paul »

Thanks for this, Lee!

FYI: If I recall, there is a bug in the binary search algorithm in "findGameIndex()". It was kind of overkill anyway; the linear search should do the trick ;-) It appears to work currently because the number of games doesn't trigger the bug.
User avatar
paul
Posts: 457
Joined: Sat May 02, 2009 8:41 am
Location: Brisbane, Australia

Re: Emuze

Post by paul »

I want to make it so that Emuze can be easily updated. I think it should be as simple as running a script and then rebuilding. Any ideas on the best way to do this? Maybe we can make a wiki dev page for Emuze and folks can upload their animations and then the script will pull all the animations from the wiki (or git or wherever); pack them via ImageMagick; call Uze's conversion tool (I forget its name); then pull the updated eeprom IDs and insert them into the code; then rebuild hex + uze. I don't know if it could also upload these new files to the wiki (hex + uze) and update git (or whatever we're using nowadays), but it seems possible.

Any thoughts? I think Emuze needs to be up-to-date to be relevant. And if the update process is not automated (for the most part), then I suspect it will continue to be poorly maintained (by me :oops: ).
User avatar
uze6666
Site Admin
Posts: 4778
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Emuze

Post by uze6666 »

Scripting would be a good way to go. Though I'm wondering if the animation bit is not making it just harder for nothing. And it take precious flash too considering we are at over 100 games and demos. Using the simplest of convention could also help. Like simply requiring a 16x16 png with the uzebox palette and using the file name as the game name (we'd use long filenames). Then we could have a simple folder full of images and parse them with a script when emuze is built. If it's that simple, I'll add it as a step when I publish a new game since I already have to make small thumbnails and such.
User avatar
paul
Posts: 457
Joined: Sat May 02, 2009 8:41 am
Location: Brisbane, Australia

Re: Emuze

Post by paul »

Good thoughts; I agree.

I'll have a look at it this weekend.
User avatar
D3thAdd3r
Posts: 3175
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Emuze

Post by D3thAdd3r »

Im sure I said it before but it seems a considerable idea to store pixels and animation details on the SD card and use ramtiles to display. Having a list of IDs and tying that all together in a file format would be a little more complicated, but at least you would have to recompile. Just keep adding to 1 .bin file. At that point flash is never an issue, and the 8x8 tiles make it even easier to copy game graphics for most.
User avatar
paul
Posts: 457
Joined: Sat May 02, 2009 8:41 am
Location: Brisbane, Australia

Re: Emuze

Post by paul »

I didn't look back through this thread, so perhaps you already mentioned your solution, Lee. It's probably best, but I think I'll leave it for a future improvement. I figure I can hack this one out in short time. But it is sad to think of Lolo with a blank stare and no blink. :( Poor little guy.
User avatar
D3thAdd3r
Posts: 3175
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Emuze

Post by D3thAdd3r »

I agree the animation adds a lot. Personally I wouldn't do anything that required it's removal, but I don't recall how tight flash is on this one either. Also, I guess it isn't really so simple to load these graphics to ram when there are multiple animation frames with different timings without implementing streaming or putting up with continual short lockups on input. Mode 13 might allow enough to preload all frames used on the screen, but then the more difficult problem (which there is no option but compromise) of choosing a pallet that fits any combination of icons.
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Emuze

Post by nicksen782 »

Hey! Emuze is a helpful tool for debugging. I've been thinking about it. It works. It is simple. But it only recognizes older games within its array of games. Sure, you can edit other data but I like being certain that I've chosen the correct entry.

I was thinking of making a web-based Emuze but then I realized that I already have Emuze through Emscripten. I should write the app for Uzebox instead.

What if, Emuze was updated with SD support? Here is my idea. Be able to read and write the entire EEPROM. This would be good for backups or offline editing. Keep the ability to edit a record and then save the whole record. This is fine. For games you would need to recompile Emuze again for each new game so that it could recognize it. I have a better idea. What if a game database could be stored on a text file on the SD card and Emuze could then read it? Now you can keep Emuze up to date without recompiling it whenever there is a new Uzebox game. Additionally, what would be stopping you from also having tile data on the SD card for the game icons? Load that into RAM tiles and you can always have an up-to-date Emuze. Just download a text file from the server. Perhaps something generated by the Online Player's database?

Emuze has not been updated in quite some time. It clearly works but it is in need of an update like what I described above.
https://github.com/Uzebox/uzebox/tree/m ... ools/emuze

I would be interested in doing an update of Emuze unless someone else would like to do it. I'm most interested in the games database, games tiles, and SD access.
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Emuze

Post by Jubatian »

Yes, I also noticed this tool, and while it is useful, it has its shortcomings presently.

It is a little complicated adventure what you propose! :) Reading the text based database and processing it when you have only 4K of RAM isn't something trivial. The database will be significantly larger than 4K. I even had this problem in the bootloader, to get to the point that it supports 255 game files on the card, and there one game file only takes 4 bytes, a start address from which the bootloader can work further as required.

Maybe something alike could work, store the addresses where the individual game descriptions start, so you can fetch them real-time as you page through the EEPROM contents. The RAM budget will be tight with the icons added, a 16x16 icon taking 256 bytes, currently 7 displayed on one screen. So with adding an SD transaction buffer, we are already above 3K (1K for descriptor addresses, 1.75K for icons, 0.5K for SD transaction buffer).

At least this doesn't have to be solved within 4K of ROM :)
Post Reply