Topic: dink's FBN Development & Fixes thread

[iq_132]

Theres a thread called "FB Alpha 0.2.97.29 Bugs Reports" where you can read about glitches and issues in games.  It would definitely be nice to have someone else helping with the glitches/bugs/etc

best regards,
- dink

I would love to see an FBA bug tracking site. There's a lot of bugs! Mostly mine!

[Barry Harris]

I'll see if I can get something setup - should be pretty easy.

[dink]

Excellent idea re: the bug tracker

[dink]

Methods to my maddness, Monday version 

Spent a while re-working and refining the taito/d_darius2.cpp & tn0100scn.cpp savestate issues & fixed the sometimes blank-background on state-load.  Darius2/Ninja Warriors/Rastan 3 - Warrior Blade is savestate-perfect now!
Another thing, I also spent the past couple days testing what was supposed to be a temporary low-khz ym2203 patch.  After a crazy amount of testing on different pc's, I decided to check in the fix.  Are you confused?    Basically it comes down to this:  if you have FM Interpolation on, (Audio -> 4-point 3rd order FM Interpolation) and play a game that uses the YM2203 chip, chances are - it'll sound like crap.  Try it yourself - make sure FM interpolation is on, (also make sure your plugin sample rate is 44100 or higher), and play the game Ghosts 'n Goblins, or Gun.Smoke.  Listen closely.  Now exit the game and disable FM Interpolation (Audio tab), then re-try Ghosts 'n Goblins and Gun.Smoke.  In theory, FM Interpolation should sound better, not worse, than no Interpolation.  Well, now that its fixed it does 

Tip of the day: sometimes its a good idea to wait for the game to initialize (aka wait for the manufacturer's logo) before loading a savestate on a freshly loaded game - especially with Taito games!

thats all for now,
best regards,
- dink

[kev]

Tip of the day: sometimes its a good idea to wait for the game to initialize (aka wait for the manufacturer's logo) before loading a savestate on a freshly loaded game - especially with Taito games!

That sounds like something is not being saved, but I guess you already knew that

Also, good work on all the fixes! If anyone ever wanted to take a look at what I did wrong with the graphics on the SMS driver that would be amazing! I really, really wish I had more time as i'd love to work on FBA again. At best I spend an hour a year at the moment and all I do is cause more issues

[dink]

That sounds like something is not being saved, but I guess you already knew that

Also, good work on all the fixes! If anyone ever wanted to take a look at what I did wrong with the graphics on the SMS driver that would be amazing! I really, really wish I had more time as i'd love to work on FBA again. At best I spend an hour a year at the moment and all I do is cause more issues

Hey there,

Re: something not being saved..
The problem is, some things are exempt from being saved (see memindex and the top of the *Scan function), the second part of the problem is, if theres too much data being saved, FBAlpha chokes up when saving the state for a few seconds, and thats not good.  So we have to find a happy medium But in reality, its probably just a global variable hidden between functions and/or something simple that I've overlooked.. 


Can you post a re-creation scenario for the SMS graphics problem?  (which game, where exactly? etc).  (in the "FB Alpha 0.2.97.29 Bugs Reports" thread, of course).  I'll certainly take a look at it, but can't promise anything since graphics are my weak point..

best regards,
- dink

[dink]

It seems like it takes about 15 minutes to compile and link a new fba executable with mingw, even after only making a minor change to the code.  To get around this, I came up with 2 scripts, one to compile and one to link - which gets the compile&link time down to about 10 seconds

lets say you're at ~/fbalpha/trunk and you made a change to src/burn/drv/taito/d_darius2.cpp, and want to build an executable real quick.

Code: [Select]

user@---------- ~/fbalpha/trunk
$ cm drv/taito/d_darius2
compile-o-matic v.0001 - usage cm dir/sourcefile

user@---------- ~/fbalpha/trunk
$ ./l.sh
linking..
copying to /home/user/fbadebugg/

user@---------- ~/fbalpha/trunk
$

"cm" does the compiling, and "l.sh" does the linking.  Here's how to synthesize the scripts, there is quite a bit involved, but the time it saves is worth it. (You have to generate a new link script (or update it) each time something new is added, like a driver or something.)
First, make sure the make process completes successfully and builds an executable, then:

Edit Makefile.mingw, search for "linking executable" and add this line below the echo:

Code: [Select]

@echo $(LD) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(lib)
Go to line #650 in Makefile.mingw, which should be "@echo Compiling $<..." and add this line below it, and save/exit editor:

Code: [Select]

@echo $(CC) $(CXXFLAGS) -c $< -o $(subst $(srcdir),$(objdir),$(<D))/$(@F)
execute this, it will change the timestamp on the d_darius2.cpp file, so it gets re-compiled with our new makefile:

Code: [Select]

touch src/burn/drv/taito/d_darius2.cpp
almost there! now run

Code: [Select]

make mingw471 > makelog.txt 2>&1 and wait about 15 minutes or so for everything to complete, or, open another shell window and run tail -f makelog.txt to see whats going on.

- stay tuned for part 2 -

[dink]

part 2 - making the scripts from makelog.txt:

load makelog.txt up in your favorite editor, and create 2 new files, cm and l.sh.
go to the very end of makelog.txt in your editor, and copy the line that looks like the one below, and paste it into l.sh:
(you'll want the entire g++ line, ignoring the "Linking executable... fbads.exe" line above it)

Code: [Select]

Linking executable... fbads.exe
g++ -pipe -std=gnu99 -O1 -mwindows -fforce-add ............
now, go up a few lines to where it says "Compiling src/burn/drv/taito/d_darius2.cpp...", and copy the entire line under it, which should start like "gcc -pipe -O1 -mwindows -fforce-ad.........", and paste it into the new file "cm"

Focusing on the new "cm" file, go to the end of the very long line and change this part:

Code: [Select]

src/burn/drv/taito/d_darius2.cpp -o obj/47/3ds/burn/drv/taito/d_darius2.oto this, and save:

Code: [Select]

src/burn/$1.cpp -o obj/47/3ds/burn/$1.o
... and there you have it!  when using the "cm" script, pass the directory leading up to the source file - relative to ~/fbalpha/trunk/src/burn/ - and the source file, without the .cpp extension.  If you also want to do work under burner, remove "burn/" from the script above (and use "cm burner/win32/sel" for example).  For an example of how to use it, refer to the top of the previous message

p.s. to make things a bit easier, you can further modify the l.sh script to copy the new executable somewhere such as your fbalpha installation directory.

best regards,
- dink

[Barry Harris]

dink,

You do realise FB Alpha has it's own dependancy checking in the makefile (enabled by default when using GCC/MinGW)?

First time you compile, everything is built, subsequent times only changed files are compiled.

The dependancy also checks for dependant files too, eg, if you change burn.h then all files that include burn.h are recompiled.

15 minutes is a long time too - it takes 2-3 minutes on my machine!

If you are devloping with MSVC enable symbols to avoid having to do a full link optimisation each compile.

[dink]

Treble Winner, yep - I'm pretty familiar with the Make process.  It really takes 15 minutes to get to the linking part, even if just 1 driver/cpp file is modified.  I think a lot of it has to do with my trusty/dusty centurys-old PC.  eh, ohwell

[dink]

Hi guys,
The last couple days I've been tearing my hair out trying to understand & possibly fix a graphics glitch in Caveman Ninja.  I have at least narrowed down the problematic code, but I just can't seem to make sense of it. 

back to the drawing board!

best regards,
- dink

[dink]

Cavaman Ninja is now a-ok - I solved the graphical issues! (finally!)
Here's some before and after shots:

Before:

[dink]

After:

[dink]

Psycho-Nics Oscar, a cool little platformer that has a powerup system similar to Gradius isn't quite right in FB Alpha.  Our hero sprite is displayed behind the trees and other stuff that should be in the background.  Here's a little pic to show how it looks in FBAlpha: * where is he hiding? *

Edit: another issue is the palette is wrong on certain things - that big weird head is supposed to have a stone-ish appearance, and the collect-em-ups are always grey and hard to read - they should be orange/yellow and easy to read.

[Arcadez]

Your on a roll dink!!! fancy taking a look at Battle Shark there's a error somewhere in the code which causes the game to
freeze just before level 2 or anytime after