Start Screen Spazzy
So I've been doing more work on FoD now that I fixed the pervious problem (another Dmod, same folder name, corrupting it) and it seems that, on my Windows 7 laptop anyway, the start screen spazzes between the loading screen image and the title screen. Kinda makes it difficult to select start or load like this.
Any suggestions? The titlescreen DOES select one of a few available background images once it gets to the menu.
It seems to stop if I delete SAVE9999, but that save is there to prevent seeing the pre-menu images every time you start the game. Have yet to test this issue on my Vista and XP computers since I'm posting this from college.
Any suggestions? The titlescreen DOES select one of a few available background images once it gets to the menu.
It seems to stop if I delete SAVE9999, but that save is there to prevent seeing the pre-menu images every time you start the game. Have yet to test this issue on my Vista and XP computers since I'm posting this from college.
//this is run when dink is loaded, directly after the dink.ini file //is processed. void main( void ) { if (get_truecolor() != 1) { say_xy("`%TRUECOLOR MODE RECOMMENDED", 0, 100); wait(4000); kill_game(); } debug("Loading sounds.."); //SOUNDS REMOVED TO PREVENT SPOILERS //Playsound(36,22050,0,0,0); int &crap; //This has been moved to coincide with the pre-title images //If you're going to play a title midi, uncomment & change the following: playmidi("ff5-2-15-searching_the_light.mid"); //The game-exist has been placed to ensure the Intro images play only the first time FoD is run if (game_exist(9999) == 0) { save_game(9999); fill_screen(0); fade_down(); sp_nodraw(1, 1); freeze(1); wait(3000); fade_up(); int &timage = create_sprite(318, 200, 0, 98, 1); sp_pseq(&timage, 98); sp_frame(&timage, 1); sp_noclip(&timage, 1); wait(6000); fade_down(); sp_active(&timage, 0); wait(200); int &timage2 = create_sprite(318, 200, 0, 98, 2); sp_pseq(&timage2, 98); sp_frame(&timage2, 1); sp_noclip(&timage2, 1); wait(100); fade_up(); wait(6000); fade_down(); sp_active(&timage2, 0); wait(200); int &timage3 = create_sprite(318, 200, 0, 98, 3); sp_pseq(&timage3, 98); sp_frame(&timage3, 1); sp_noclip(&timage3, 1); wait(100); fade_up(); wait(6000); fade_down(); sp_active(&timage3, 0); wait(2000); } //This if statement fixes the Midi delay if the game has been run before if (game_exist(9999) == 1) { wait(3000); } //Make sure the screen isn't locked now. Kinda fixes a bug where if you die //when the screen is locked, the "screenlock" bars remain on the title. screenlock(0); //Get the "sprite #1" (which is actually Dink) set to be a mouse pointer unfreeze(1); sp_nodraw(1, 0); sp_seq(1, 0); sp_brain(1, 13); sp_pseq(1,10); sp_pframe(1,8); sp_que(1,20000); sp_noclip(1, 1); //This is where we create the TITLE SCREEN. This line is ok if you're using //a 640 x 480 full-sized bitmap as the title (as I do, usually). If you //don't, be sure to change this line to fit. //Select one of the FoD backgrounds at random for the titlescreen int &r = random(4, 1); &dinklogo = create_sprite(426,344, 0, 453, &r); //&dinklogo = create_sprite(426,344, 0, 453, 1); sp_que(&dinklogo, -800); sp_noclip(&dinklogo, 1); //Fade Up from the final pre-menu image, and delay the button appearances, then set midi's to loop fade_up(); wait(3000) loopmidi = 1; //Create the START button.... //&crap... Script Cut Here
Can't see what might be causing that... will have a test maybe.
Does it perhaps stop if you do
instead of putting the game_exist directly in the if statement?
Some nitpicks:
Killing the game after the truecolour warning seems to imply it's required, not recommended
Why use three variables for the images when one would do? Or no new ones if you use &crap or something.
There's no semicolon after the last wait(), though that probably doesn't affect anything much.
Edit: If game 9999 exists it doesn't do a fill_screen, maybe that's it.
Does it perhaps stop if you do
&something = game_exist(9999); if (&something == 1)
instead of putting the game_exist directly in the if statement?
Some nitpicks:
Killing the game after the truecolour warning seems to imply it's required, not recommended
Why use three variables for the images when one would do? Or no new ones if you use &crap or something.
There's no semicolon after the last wait(), though that probably doesn't affect anything much.
Edit: If game 9999 exists it doesn't do a fill_screen, maybe that's it.
Aha, moved the fill_screen and it worked.
And thanks for pointing out the truecolor note Problem with playing without it on, is that all the questlog images and tons of stuff look... horrible. Though the kill_game was going to be removed, I may just edit it to say required.
Cheers SH.
And thanks for pointing out the truecolor note Problem with playing without it on, is that all the questlog images and tons of stuff look... horrible. Though the kill_game was going to be removed, I may just edit it to say required.
Cheers SH.
Did you make sure the graphics that look wrong are in the Dink pallet? Make sure it's a 24-Bit BMP, you can ensure this by saving it over a default Dink graphic.
Yeah the images are a bit too high-quality and detailed for that So truecolor's staying required.
"Make sure it's a 24-Bit BMP"
8-bit... 24-bit be truecolour
8-bit... 24-bit be truecolour
Whatever the image quality, they're working. Probably 24-bit, don't know much about pallet stuff and don't really feel a need to know more.
Regardless, the problem I asked about is solved. If this image thing becomes an issue they're in the FoD demo as well (basing em all off the first log-image file as I make the quest log pages) if ya want to look into it, otherwise I see no other problems right now.
/derailed
Regardless, the problem I asked about is solved. If this image thing becomes an issue they're in the FoD demo as well (basing em all off the first log-image file as I make the quest log pages) if ya want to look into it, otherwise I see no other problems right now.
/derailed
You guys are so nerdy!!
Its.... beautiful...
Its.... beautiful...