Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / SYNC producing blue background screen

Author
Message
Agent
21
Years of Service
User Offline
Joined: 7th Sep 2004
Location: Sydney, Australia
Posted: 20th Jul 2011 04:03
Ok, so this feels like a newbie question and I'm sure I'm overlooking something straightforward, but I'm not quite sure what's going on here.

I'm working on a main menu function for my latest project (Solodor). I'm trying to create a fade to black, by drawing a black box covering the entire screen at a certain alpha level within a for...next loop, and at each iteration increasing the alpha level of the black box, resulting in a fadeout.

Now, there are a couple of loops ahead of this FTB that include a SYNC at the end (login screen, then the actual mainmenu screen with the options). When I select an option from the menu, I flip to my FTB routine before fading back in at the new screen.

Here's my pseudocode for the FTB loop:



This used to work, before I made the recent modifications to my mainmenu routine, and I'd get a nice smooth FTB. However, since I added an additional loop ahead of my mainmenu that requests a username and password (within a loop that has a SYNC at the end), my FTB loop is now resulting in the screen being painted blue (backdrop?) instead of fading out.

The appearance of the blue paint seems to indicate that I'm violating a doublebuffer rule but I can't figure out why; it's fairly straightforward logic, that used to work. My new loop that comes in ahead of the FTB works just fine without blue paint, so I'm not breaking any doublebuffer rules there.

I don't get it. What causes SYNC to throw blue paint? I need scenarios that I can narrow down.

Any help out there?

Agent
21
Years of Service
User Offline
Joined: 7th Sep 2004
Location: Sydney, Australia
Posted: 20th Jul 2011 04:08
Even if I remove the WAIT command, I still get blue screen. Seems strange. What am I missing?

CSGames94
18
Years of Service
User Offline
Joined: 27th Dec 2007
Location:
Posted: 20th Jul 2011 05:49
Try using this "backdrop off"
Agent
21
Years of Service
User Offline
Joined: 7th Sep 2004
Location: Sydney, Australia
Posted: 20th Jul 2011 06:25
That's the first thing I made sure I was doing, and I have been. Must be something else.

GIDustin
18
Years of Service
User Offline
Joined: 30th May 2008
Location:
Posted: 20th Jul 2011 06:34
Does the problem go away once you leave the FTB loop?

I hate these kind of problems that just don't logically make sense. I sure hope you figure this out. I assume it is happening with Solodor, and I would hate to see it delayed due to this.

Dar13
18
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 20th Jul 2011 06:51
Could you give us some specific code? I can't recreate your problem based on your description.


Grog Grueslayer
Valued Member
21
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 20th Jul 2011 10:02
Have you tried grabbing the background before you fade to black?

In the following code snip if you rem off the background grab and the pasting of the background it'll show a blue screen even though it should show a bunch of random boxes.



IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 20th Jul 2011 15:42
Quote: "I need scenarios that I can narrow down."

The blue backdrop is enabled by the following:
- Creating a sprite
- Creating an object
- The BACKDROP ON command

Sprites can be 'fixed' by using the SET SPRITE command, switching backsave off, and the others can be 'fixed' with the BACKDROP OFF command.

DVader
22
Years of Service
User Offline
Joined: 28th Jan 2004
Location:
Posted: 20th Jul 2011 17:24 Edited at: 20th Jul 2011 17:27
It seems DB Pro automatically overides backdrop off if you make sprites. I tend to force the background image to be the one I want, by pasting it down before any sprite operations. For example.

As long as you paste your background image down first, all your other operations should be drawn on top of it. Any alpha operations to your sprite would still work fine.

http://s6.bitefight.org/c.php?uid=103081
Agent
21
Years of Service
User Offline
Joined: 7th Sep 2004
Location: Sydney, Australia
Posted: 22nd Jul 2011 12:08
I kind of already knew what was causing it (it's the 3D engine kicking in because I made a sprite, which is actually a 3D object that happens to only have two dimensions) but my experimentation was a bit confusing. The issue is occurring on my main menu screen, and the first time the main menu is run, my sprite displays just fine without the backdrop coming into play and everything looks great until I start the FTB, then the backdrop rolls up. That's confusing all by itself, but the thing that threw me even more was that once I am in the main game, and I navigate back to the main menu screen again, everything works exactly as expected, including the FTB. It's only the very first FTB that is executed that causes the backdrop to show up.

Very odd.

Showing the code would be a bit cumbersome as it's quite a long mainmenu routine (a few hundred lines - it's not just a draw of a few boxes then wait for mouse input... there's background animation and lots of special visual effect code going on). The problem that results in the backdrop showing up could be anywhere in my draw code spanning all of those lines so it's not practical.

Ian, thanks for the explanation on what triggers the backdrop. However, I'm afraid I don't understand any part of the last line of your post. What do you mean by "fixed", and what "others" do you mean what you refer to the BACKDROP OFF command?

I've worked around it by adding transparency to the image file itself (what I originally wanted to do was make a nontransparent image transparent through alpha levels after making the image a sprite), so it's no longer an issue. I'm still a bit curious about it though, it's very inconvenient and there's no obvious reason for it.

Still, Solodor has a nice sweet looking new login and main manu screen now. It's very awesome

Rich Dersheimer
AGK Developer
17
Years of Service
User Offline
Joined: 1st Jul 2009
Location: Inside the box
Posted: 22nd Jul 2011 23:07
Maybe it's related to the need to do two "syncs" at the start of a program?

like

sync on:sync rate 60:sync

so that your first "sync" in the main loop is the one that actually syncs everything up.

Just guessing...

GIDustin
18
Years of Service
User Offline
Joined: 30th May 2008
Location:
Posted: 23rd Jul 2011 01:29
Agent,

I know by looking at the progress of your game that you are well versed in DBP, but did you try the one command that IanM suggested? After you create the sprite, "set sprite <spritenum>, 0, 1". I know that in most my games, once I create a sprite, that is the very next command.

enderleit
19
Years of Service
User Offline
Joined: 30th May 2007
Location: Denmark
Posted: 23rd Jul 2011 21:40
I used a black OR white sprite and scaled it to the screen size in my demos "Oldschool" and "Darkness" to create fade in/out's. Works like a charm. Create a sprite and set the priority so it's always in-front, and scale it to the screen size... Then just modify the alpha value on the sprite...

Agent
21
Years of Service
User Offline
Joined: 7th Sep 2004
Location: Sydney, Australia
Posted: 25th Jul 2011 09:24
Yeah, I do a similar thing, except there's no need to use an external file (the black sprite that you scale to screen size) cause you can just draw a black box to fill the whole screen with alpha which is even easier

I didn't try Ian's command as I didn't (and still don't) understand what he's doing with it and I believe in understanding something before implementing it. The backsave and transparency of a sprite is set to on by default, so his command disables the backsave without deactivating transparency. As far as I can tell, all that'll do is create a "Hall of Mirrors" effect as I move my sprite across the screen.

Perhaps I'm misunderstanding and the command will solve all my troubles after all, but I don't want to try to implement a fix that I don't fully understand (as it might create side issues that I'll subsequently be unable to fix as I won't know the cause and regardless, I won't learn anything). Can someone explain why turning off the backsave on one sprite will stop the backdrop from appearing across the entire screen?

Rich Dersheimer
AGK Developer
17
Years of Service
User Offline
Joined: 1st Jul 2009
Location: Inside the box
Posted: 25th Jul 2011 13:04 Edited at: 25th Jul 2011 16:12
The SET SPRITE command is not quite what it seems to be. See this thread for more.

The command sets the backsave for ALL sprites, not just the one in the first parameter. In fact, you can call SET SPRITE without having created a sprite at all.



As you can see, this gives you the ability to draw graphics or text on the screen outside of the display loop - you don't have to keep drawing them every cycle.

Agent
21
Years of Service
User Offline
Joined: 7th Sep 2004
Location: Sydney, Australia
Posted: 28th Jul 2011 11:37
So if I stick a SET SPRITE 1, 0, 0 somewhere in our top of code initialisation block, I'll never see the backdrop again no matter what?

enderleit
19
Years of Service
User Offline
Joined: 30th May 2007
Location: Denmark
Posted: 28th Jul 2011 12:32
Quote: "Yeah, I do a similar thing, except there's no need to use an external file"

Actually that's what I meant. I don't load an image, I just create a black image runtime, and use that.

GIDustin
18
Years of Service
User Offline
Joined: 30th May 2008
Location:
Posted: 29th Jul 2011 04:15
Quote: "So if I stick a SET SPRITE 1, 0, 0 somewhere in our top of code initialisation block, I'll never see the backdrop again no matter what?"


It depends on how you are using sprites really. If you are like me, you are only using the sprite for its adjustable transparency. With mine, I hide them after creating them, and "paste sprite" when I need to draw them to the screen. After I create the sprite, I "set sprite <sprite>, 0, 1". I haven't had any problems since.

If you are letting the sprites stay visible and letting DBP draw them whenever it is that they draw them, then I am not sure the best way to proceed. I much prefer having control over how and when my sprites are drawn.
Agent
21
Years of Service
User Offline
Joined: 7th Sep 2004
Location: Sydney, Australia
Posted: 31st Jul 2011 20:10
I'm the same. I never allow sprites to remain on the screen, they're hidden in the line immediately following their creation. I use sprites for lots of different adjustibility: Alpha, diffuse, rotation and scale are the ones worth mentioning. Then I use paste image to draw them to the screen.

However, the 3D engine is activated as soon as you create any 3D element, and since a sprite is a 3D element (it's a 2D plane automatically rotated to face the camera) you have to deal with the backdrop right away.

I usually have no problem with this since you can turn it off and/or draw your own background over the top of it, but on this occasion none of that was working and I experienced the trouble described in the OP. Doesn't make much sense that the backdrop appears at all under these circumstances, let alone only the first time and then never again (really strange).

Login to post a reply

Server time is: 2026-07-10 17:19:59
Your offset time is: 2026-07-10 17:19:59