Release DraStic Nintendo DS emulator


Exophase, I have a small request.

Could you maybe take the time to look into this particular homebrew game and see why it is crashing?

Me and a friend did it together years ago (well, he ported it to the DS after I did a PC/SDL original version) and it's really as simple as it gets. All you do is move around and avoid the falling objects and get the highest score possible.

As of right now it boots, but crashes right away when the game wants to write a save file to the filesystem (for highscores) and I think it tries to write to the root of the flashcard if I remember things right..

It's built with PAlib and maybe the crash is related to FAT routines and crashes when it can't write the file, but that's just a guess.

I'm sure you have much more important things to address, but if you could take a few moments and have a look at it and have it working in the next build that would mean a lot.

LINK

Thanks.
 
I am not sure how much that would speed up the emulation for the other screen, but this may add up some more performance "for free" to many games where the second screen is pretty much useless. Such settings would need to be saved in the profile for each game, i believe.
Thinking of the "guitar hero" version of the ds. Think its name is rockband. On screen is showing the keys to press, the other one rockband. The key screen is important, the rockband screen can have frameskip 6 or something ;) .
 
Exophase, I have a small request.

Could you maybe take the time to look into this particular homebrew game and see why it is crashing?

Me and a friend did it together years ago (well, he ported it to the DS after I did a PC/SDL original version) and it's really as simple as it gets. All you do is move around and avoid the falling objects and get the highest score possible.

As of right now it boots, but crashes right away when the game wants to write a save file to the filesystem (for highscores) and I think it tries to write to the root of the flashcard if I remember things right..

It's built with PAlib and maybe the crash is related to FAT routines and crashes when it can't write the file, but that's just a guess.

I'm sure you have much more important things to address, but if you could take a few moments and have a look at it and have it working in the next build that would mean a lot.

LINK

Thanks.
That's almost certainly due to the use of DLDI which isn't implemented (yet, hopefully!). I think the emphasis for these releases is to get as much commercial compatibility as possible.

D.
 
Hoping to get another release out in a few days or so, so making another call for updates on the compatibility list. Right now we've got 48 red, but only 14 for 1.2.0.0. Ideally there should be no or very few red entries for old versions; they should only be there if it's still broken in the new version but in a different way that warrants a different description. Of course that's never going to happen completely, but I'd appreciate it a lot if the people who entered red and orange entries for 1.1.0.0 could retest them for 1.2.0.0 and update the list. It's tedious work but it's a lot easier for the original people to do it than for new people to try to reproduce something that may never have a problem.
 
Please make a button to switch the displays from full top/full bottom/side by side

and

please make a load the next rom in the list.

Id love to load rom 0001 - Electroplankton.... test for a few minutes and hit a button to automatically test the next rom 0002 - whatever the hell  ;)

Let will let us test the roms in order on a spreadsheet nice and easy.

http://www.ds-scene.net/?s=releases&s2=1&o=a
 
Last edited by a moderator:
The following has already been implemented for the next version:

- 1x:2x and 2x:1x display modes

- Key Z to toggle between horizontal and vertical display

- Key C to toggle between multiple and single screens

(and key X still toggles active screen)

So please everyone stop asking for me to implement these things :p

As for a "load next" button, I don't think that's something I want to do since that's a really specialized function that has very limited general usefulness. Maybe something more generally useful and almost as helpful in this situation would be to press shift + M to take you directly to the load game option in the menu, and to have the menu seek to the currently loaded game. Then the sequence is just shift + M, down, then B to load the next game, and this is something that's relatively easy to implement with the current codebase.
 
Last edited by a moderator:
Has anyone been able to play SMT:Strange Journey on this?

As soon as I boot the thing, it says "Could not access the data. Turn the power OFF and reinsert the DS card"

EDIT: I got a fresh copy and it works fine. Weird.

EDIT2: Now it did it when I tried to save. Is this some AP?
 
Last edited by a moderator:
Sounds like issues with the database used to determine save file size

First time it sounds like the rom's crc32 wasn't matching.  

The second time seems to indicate that  the save size listed in the database for that game is incorrect.

*looks it up*   hrm...  yeah according to ADVANsCEne both versions of that game use a 64k EEPROM,  but it's in the database as an 8k EEPROM.  That would certainly explain the issue you describe.

If you want to fix it yourself, do a text search for Strange Journey, then change the save size on the following line from 0x2000 to 0x10000.

you may need to do that twice as there are two entries for that game and I don't know which one matches the version you are using.   

If you do manually change it, don't forget to delete the modified database file from appdata when the next version of DraStic is released though.

- Neelix
 
Last edited by a moderator:
I'm looking forward to trying my roms with a new version!

By now they all had the "save size issue" Neelix is describing above (I dumped them myself - all of them are german versions).

I managed to run some homebrew games, though...
 
Sounds like issues with the database used to determine save file size

First time it sounds like the rom's crc32 wasn't matching.  

The second time seems to indicate that  the save size listed in the database for that game is incorrect.

*looks it up*   hrm...  yeah according to ADVANsCEne both versions of that game use a 64k EEPROM,  but it's in the database as an 8k EEPROM.  That would certainly explain the issue you describe.

If you want to fix it yourself, do a text search for Strange Journey, then change the save size on the following line from 0x2000 to 0x10000.

you may need to do that twice as there are two entries for that game and I don't know which one matches the version you are using.   

If you do manually change it, don't forget to delete the modified database file from appdata when the next version of DraStic is released though.

- Neelix
I can probably do this. where do I look for the file? Should I open it with a database manager,hexedit, or mousepad?

EDIT: Nevermind, Exophase helped me over irc. The fix works nicely!
 
Last edited by a moderator:
There's one rather simple request that I'd like to see: an option to change buttons, esp. emulator buttons. I.e. I personally find it a bit annoying to press X for the display change and would like to set it to 1 or other "nearer" buttons. But even game buttons changeability would be much appreciated - there are some games that put buttons in a weird way, so customising on a game-to-game basis would really come in handy sometimes!

Also, stretched fullscreen. I'm one of those suckers... :)
 
DraStic is reviewed in the new Pandoralive.info blog : http://www.pandoralive.info/?p=5

teaser3.png
 
I don't know if this is a bug proper, but I found what I imagine to be some color problems.

I've recently played some Professor Layton and the Curious Village. In it, there is a recurring screen where you input your answer by scribbling i.e. the number '2' in a special writing area, and the game recognises your handwriting and puts a typeset '2' in a black box above. Good enough description? Anyway: The color of the typeset number is very, very dark, to the point of being almost invisible. There is a similar problem in one specific puzzle, where you are supposed to cut up a block of chocolate - The lines showing where you have cut is of an almost invisible color.

This is of course not something that in itself warrants a fix - "Oh, noes, we must immediately fix Prof. Layton!!!" :D - but it might be a more general problem of some color bits going wrong - something fishy in alpha decoding or something, or that sometimes lines or numbers are rendered under rather than over some layer, or something. Anyways. This is not a very good bug report :) but it is an attempt.
 
I fixed decal blending at some point (had to to get Picross 3D working so I know it was after the last release, although I seem to have forgotten to put it in the change log..) and it made the name entry at the start of Prof Layton appear correctly, this is probably related to that.
 
Last edited by a moderator:
I suppose digging out a screenshot or some youtube video would help to see what you are talking about.
Yes, I tried, but I had a limited time before I was leaving for the train :) I'll see what I can find later tonight.
 
Back
Top