Release DraStic Nintendo DS emulator

[porg]

I'm not really sure what you're asking..

My question was: How and when is drastic_file_info.txt considered(read) / updated(written to) ?

the lines of drastic_file_info.txt tie a file names to gamecard ID and title.

That was clear to me, but thanks for confirming.

The directories are scanned regardless of the drastic_file_info.txt file, the file is just there so it can quickly display some game data (title, header title, game code) without having to scan the game files themselves.

So DraStic can display a game list to the user immediately, but in case the dir content changed, this list gets updated (in the background). If the game list update is completed, is the game list view then immediately refreshed? Accompanied with a message/overlay "ROM list has been updated", or just the list changing? The latter is possibly un/noticed by the user…

Scanning the directory is fast, even if you have thousands of files, but (depending on your SD card) scanning thousands of zip files can take a long time, up to dozens of seconds.

That could be omitted, therefore sped up, if my suggested check nr.1 would be implemented:

Mod-date of "drastic_file_info.txt" and "." are the same?

If new files are encountered that weren't in the info file they're added to it. Old files entries aren't removed, it only appends to the file.

So sooner or later you will have orphans in your game list! Games the user deleted on purpose from the SD card, but which still "clutter" the game list, and which would fail should they be attempted being launched.

It goes without saying that checksumming all of the files would defeat the purpose of the info file being there, since it'd be much slower than getting their header. The system fails if you change the directory so a file with the same name now contains a different game. I could check for this by putting a file timestamp in the info file. But this is a pretty strange and unusual thing to do so I don't bother.

Agree.

In the latter 2 cases the user has to delete the drastic_file_info.txt as a whole, so that it gets regenerated), or if s/he understands the format of the file, erase the line with the orphaned game or correct the title (for the very very rare case where you place a new ROM under the same file name). This speaks for having drastic_file_info.txt visible, else a user suffering from the aforementioned phenomenona, has almost no way of guessing why his game "b" is still shown as "a" or why "c" is still shown in the game list although its file gone.

Or s/he may find this forum post, when trying to troubleshoot. 

 

[Exophase]

I'm still not sure you fully understand.

drastic_file_info.txt is a supplement to the directory list that is scanned every time the directory is opened. It's not there to provide a list of what files are in the directory, it's there to provide information about files. It doesn't matter if there are orphaned files in the list, they won't be displayed if they're not in the directory. I could rebuild the file but there's no really pressing need to, I doubt you will carry tens of thousands of orphans in it. And this way if you put the file back it's still there.

No the list isn't displayed immediately or gets updated in the background - it will be scanned fresh every time the directory is entered and if there's something new it'll be added to the info file. If you add a file to the directory while drastic is running it won't get updated until you leave the directory or the menu but that's normal for most programs. If you have the option selected to display the list by file name it scans the list and that's it. But if you have one of the other two options, that displays the list by game title or header title + game code then it uses entries in drastic_file_info.txt, if present, to identify the games in the database.

There's no reason to look at the file creation time of the directory to speed up anything. Scanning the directory is fast. I don't want to have to go back to having to scan every file every time a new file is added or removed from the directory.

I don't see why someone would have the same filename now contain a different game in the first place. If they do that they can still see the file by file name and they'll probably realize what happened. If I get complaints I'll consider adding timestamp validation but otherwise I'm not interested.

 

[ZXDunny]

Could you not store the files in the Drastic Appdata directory, and read them out as needed for each directory you enter? Maybe encode the path into the filename somehow... Just a thought, mind.

D.

 

[pmprog]

You could try an SQLite DB in the AppData folder with a simple table of Folder Name, Filename, and ROM Information.

 

[_wb_]

Let's not over-engineer this.

A hidden file in the directory itself is a good approach: if you rename or move the directory, the cache file moves with it.

Let Exophase focus on the emulator itself instead of trying to perfect the launcher.

 

[porg]

@Exophase: Thanks for your most recent explanation. (supplement!) Now it's clear how DraStic's ROM discovery works! No more questions. (You could just copy&paste it into your FAQ, worthy info)

And I agree with _wb_: An index file near the ROMs is a proper way for storage.

 

[apersonthinks]

Found a couple of homebrew that work:

Rhythm/platformer thing (slow):

http://www.destructoid.com/ds-homebrew-everlasting-monkey-love-30739.phtml

And the infamous "cat mario" (game itself occasionally freezes, emulator still works fine):

http://dl.qj.net/down/syobonaction-ds-rc1.html

 

[LTStone]

any news , hows progress?

 

[rohezal]

he is writing an integer only renderer and working to optimze the geometrie engine. and he said he will try to release it this summer, when i remember it correctly.

 

[ekianjo]

Yeah. It takes time. Its normal.

 

[LTStone]

Nope no rush, just wondering how things were going. 

 

[Exophase]

Sorry, I missed my own thread somehow.

I've been working quite a bit on things these past few weeks.

My original plan was to make an all new all-integer version of the renderer that was as accurate as possible. While doing this I found out two things. First, the more accurate I made some parts, the more it screwed up other parts, because the DS does weird hacky things that have to be compensated with other weird hacky things. I eventually hit my limit of dealing with this nonsense and decided to push it off into the future, maybe for a spinoff project at a later date. A relatively sensible implementation seems to look good enough (like, literally, visually look) in the things I've tested.

The other thing I found is that, much to my chagrin, a simple pure integer version didn't offer this big easy speedup I wanted - instead it was substantially slower. The big reason for this is because it traded float multiplications and adds, which are slow, and float divisions, which are slowish, for int multiplications and adds which range from fast to slow if they're 64-bit (which the compiler version I'm using sucks with) and integer divisions which are really slow since there is no hardware support for them. So I found a good compromise, which is to use floats for interpolation step coordinate generation and convert them to 16-bit fixed point integers for interpolating the actual values, using integers everywhere else. This way I could leverage acceptably fast float divisions against small-ish integer everything-else, and as a first approximation this was at least faster than what I started with.

Since then I've been aggressively optimizing everything into multiple passes and converting it to NEON as I went. So the idea of having this nice and easy C version with simple optimizations is a long forgotten pipedream, but it's all moot now because I've already gone way past that point. I don't want to reveal any specifics just yet, when the time is right I can post my performance tracking data.

I've also been working on optimizing the geometry engine, this is actually what I started with before I determined that I felt like working on the renderer instead. This involved pretty much a total rewrite of the C code, vastly rethinking how it should work. I've only done a bit of work on the NEON side of that, but it's still tangibly better so far.

 

[ekianjo]

Thanks Exophase for the update. Sounds like it's never straightforward to optimize things for emulators, but glad there is some kind of progress. When you have performance data to share please do

 

[Linux-SWAT]

Glad to read.

 

[Askarus]

:lol:

 

[rohezal]

Very excited about the news . Will try it, when it is released^^.

 

[PokeParadox]

Ooooooh can't wait to see future versions Exo.

 

[Exophase]

I guess I didn't see the new posts because of the forum it's in. Since this is being used beyond the compo could a mod move it somewhere else?

 

[moxie]

Sure thing. Software News seemed relevant to me.

Automatic message


This topic has been moved from "Pandora → Coding Competitions → DragonBox Coding Compo 2012/2013" to "Pandora → Software → Software News".

 

[notaz]

I've got my hands on WIP version, all I can say you're all in for a treat!