#58146 - Onori - Fri Oct 21, 2005 10:04 am
I just updated libnds with devkitpro and all the games projects I was coding don't work anymore ... do you think about backware compatibility ?
the last time I updated I also had to modify my code, especially about console function that didn't exist anymore..
#58148 - Mollusk - Fri Oct 21, 2005 10:21 am
libnds is still pretty young, so things can change all the time... They've always said so, and even though it's kind of a pain, it can be necessary...
In the end, it IS better to have to update your code once every so often and have an always better libnds, than having to stick with an old and perhaps buggy version...
Once the DS dev scene will be a little more mature, this won't happen anymore :)
_________________
PAlib official forum : http://www.palib.info
PAlib official tutorials: http://www.palib.info/wiki
Updates, help, code examples, tutorials, etc...
#58151 - Onori - Fri Oct 21, 2005 10:32 am
updating all the code of all the project being developped with libnds take more time than making backware compatibility I think :/
#58152 - Mollusk - Fri Oct 21, 2005 10:37 am
The thing is, if you keep leaving backward compatibility code all the time, when exactly will you be able to remove it from the lib ? There'll always be someone using the old stuff, just because that's how they got use to it, and it never ends... The only way to 'force' people to use the new stuff is be not allowing that backwards compatibility... Even though it can feel wrong, in the end it's better for everyone...
_________________
PAlib official forum : http://www.palib.info
PAlib official tutorials: http://www.palib.info/wiki
Updates, help, code examples, tutorials, etc...
#58154 - Onori - Fri Oct 21, 2005 10:41 am
this time I can't understand why my code don't work anymore, I just call a swiWaitForVBlank(); and it freeze, where as with the libnds from before it just worked fine :(
#58155 - Mollusk - Fri Oct 21, 2005 10:43 am
I think wintermute was looking at that, you aren't the only person to have had that bug...
_________________
PAlib official forum : http://www.palib.info
PAlib official tutorials: http://www.palib.info/wiki
Updates, help, code examples, tutorials, etc...
#58156 - Onori - Fri Oct 21, 2005 10:47 am
I won't call it "better" if it freeze on a simple waitforvblank...
#58158 - cory1492 - Fri Oct 21, 2005 11:40 am
I personally have a batch file that takes the libnds and devkitARM dirs and renames them to libnds-R16 and devkitARM-R16 and puts the R15 ones in their place. When I want to be confused about escape sequences I switch to the R16 lib/chain and when I want to actually code something I switch to the R15 one.
I remember spending weeks trying to find out why my ebook data would not load with R13 to R15 switch up, everything compiled fine but resulted in blank screens. Turned out some memory areas got moved so that the data that was loaded along with the ARM9 binary got overwritten in memory... what a waste of a couple weeks when I could have actually been doing something other than scratching my... well, you can get the picture. The upgrade to the next version was well worth it though, binaries come out less than 1/2 the size (although it does take a bit longer to run on hardware and is less likely to work out on emulators)
It would be nice to see some straight forward info presented when the toolchain is changed so signifigantly for those of us who arent "in the loop" with the dev's, but for the time being I am staying away from R16 as the changes were so big that there is likely to be bugs for a while... till then, the rest is downloadable from the sourceforge site and you can always go back and forth till it all gets straightened out...
#58162 - NoMis - Fri Oct 21, 2005 12:15 pm
The dev scene around the DS is still pretty young and people find out how to solve things the better way. Sometimes this means a defind API is not suitable anymore.
I guess once we get a better understanding of the system with more practical knowlege the api will get to a state where it keeps being backward compatible.
In Java there is a way to mark a method deprecated to ease the process of moving to a better api. Is there a similar functionality in C/C++ that could be used?
NoMis
_________________
www.gamedev.at - The austrian gamedev site
hde.gamedev.at - The Handheld Dev Env plugins for Eclipse
#58168 - wintermute - Fri Oct 21, 2005 1:23 pm
| Onori wrote: |
| I won't call it "better" if it freeze on a simple waitforvblank... |
Comments like this really aren't helpful.
When you find a bug of some sort you need to provide sample code that doesn't work then people might be able to help you. There is a tracker provided for bug reporting, see http://www.devkitpro.org/bugs.shtml
I've heard several reports of this nature which appear to be emulator bugs. These should be reported to the emulator authors if the code can be verified to work on hardware.
#58171 - Onori - Fri Oct 21, 2005 1:34 pm
for me it work on emulator, but not on hardware :/
I'll try to isolate the code that freeze
#58177 - tepples - Fri Oct 21, 2005 2:42 pm
| NoMis wrote: |
| In Java there is a way to mark a method deprecated to ease the process of moving to a better api. Is there a similar functionality in C/C++ that could be used? |
There isn't in ANSI C, but there is such a way in GNU C.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#58219 - dnt - Fri Oct 21, 2005 7:07 pm
The new support for nested interrupts appears to confuse the emulators (or maybe is actually broken). The new libnds does interrupt handling in a chunk of assembly code - the previous versions just had a relatively simple C function.
Furtunately, the problem is easily fixable - just ignore the new arm9 interrupt handling routines that were added to libnds (arm7 ones appear ok).
On the arm9, setting up an interrupt handler using irqInit, irqSet etc seems to fail (initialisation works, but the program later hangs waiting for vblank).
The fix is to just paste the old libnds interrupt handling code into your main arm9 program and use that to setup you interrupt handler:
void on_irq()
{
if (IF & IRQ_VBLANK) {
// Tell the DS we handled the VBLANK interrupt
VBLANK_INTR_WAIT_FLAGS |= IRQ_VBLANK;
IF |= IRQ_VBLANK;
} else {
// Ignore all other interrupts
IF = IF;
}
}
void InitInterruptHandler()
{
IME = 0;
IRQ_HANDLER = on_irq;
IE = IRQ_VBLANK;
IF = ~0;
DISP_SR = DISP_VBLANK_IRQ;
IME = 1;
}
#58231 - tepples - Fri Oct 21, 2005 8:28 pm
| dnt wrote: |
| The new support for nested interrupts appears to confuse the emulators (or maybe is actually broken). |
Everything confuses the emulators. Right now they aren't even as compatible as Nesticle.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#58243 - GPFerror - Fri Oct 21, 2005 9:12 pm
all my old code from r16a , compiled fine and runs fine in the emulators with r17, but im not using any new features from r17 yet.
and my older code from <r16 just required me to change some of the variable names that changed in r16 to get them to compile and they run fine in the emulators as well.
Troy(GPF)
#58245 - wintermute - Fri Oct 21, 2005 9:25 pm
| dnt wrote: |
The fix is to just paste the old libnds interrupt handling code into your main arm9 program and use that to setup you interrupt handler:
|
That's not a fix, ARM interrupts require a dispatcher, the dispatcher *must* be implemented as ARM code. The old code cannot be nested or used in thumb code.
The *emulators* are broken, not the library (well, in this particular case anyway) :P
#58532 - Onori - Mon Oct 24, 2005 10:02 am
wintermute > thanks for the bug fix, it resolved all my problems :)