Page 2 of 2

Re: Emuze

Posted: Sat Jan 24, 2015 11:59 pm
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.

Re: Emuze

Posted: Sun Aug 02, 2015 12:48 pm
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: ).

Re: Emuze

Posted: Sun Aug 02, 2015 9:00 pm
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.

Re: Emuze

Posted: Mon Aug 03, 2015 4:30 am
by paul
Good thoughts; I agree.

I'll have a look at it this weekend.

Re: Emuze

Posted: Mon Aug 03, 2015 5:05 am
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.

Re: Emuze

Posted: Mon Aug 03, 2015 2:06 pm
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.

Re: Emuze

Posted: Mon Aug 03, 2015 2:43 pm
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.

Re: Emuze

Posted: Mon Jan 21, 2019 10:43 pm
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.

Re: Emuze

Posted: Tue Jan 22, 2019 8:23 pm
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 :)