So Grabsprite allows a portion of the backbuffer to be grabbed, which serves me fine, but I was wondering if there was a way to grab the front buffer (ie. the screen) apart from the really slow getpixel? Either that or copy the frontbuffer to the backbuffer would be fine.
Cheers
The frontbuffer (screen) is the image you see after using SHOWSCREEN, so just use GRABSPRITE just before SHOWSCREEN.
Are you wanting to grab the whole screen for a screenshot function? If so check out SAVEBMP.
Yeah, that's what I'm doing at the minute.
Basically I wrote a fade routine. I currently make sure that when I do the fade that I call my drawscreen routine but specifically set a flag to make sure it doesn't use showscreen. Then a grabsprite the whole thing and use a gradual reduced alphamode on it until it basically fades away. I don't use blendscreen because I can fade at anytime and I haven't got to the section I want to blend into yet. Fair enough I could have written it better in the first place, but I sort of just bunged it all together being new to GLB. And anyway it would be nice to fade at any opportunity and not worry about what you did before. Which basically brings me to this. So you pop into the fade routine from any place, and it copies the frontbuffer to a sprite (or at least copies the frontbuffer to the backbuffer and then does a grabsprite), and then proceeds to use this sprite with alphamode to effectively fade the screen away. Nice and simple, no mucking around, just fade whatever is on the current frontbuffer basically.
If no way of doing it then no worries as it code-roundable, but it would just make things a little easier when you don't want to think ahead too much.
Cheers
The front buffer is what is on the screen, Never touch this. You draw to back-buffer, swap front to back and drawn on your new backbuffer. If you want to fade the screen, draw the new screen on a sprite and draw this over your backbuffer after the normal screen is done. You can also just create a black sprite and draw this over your screen just before showscreen with decreasing amount of alpha, this way you can fade while doing animations onscreen just like normal.
If your fade routine is working, what is the problem?
Here's a VERY simple fade routine that grabs the screen and fades in/out in real-time. The screen is grabbed before the routine, but there's no reason you couldn't grab the sprite in the main loop then run the fading routine as a function, achieving the same result.
GLOBAL dir, a
SETSCREEN 640,480,1
// DRaw lots of rects on screen for grabbing
FOR n=0 TO 100
DRAWRECT RND(640),RND(480),RND(64),RND(64),RGB(RND(255),RND(255),RND(255))
NEXT
// Grab the screen image
GRABSPRITE 1,0,0,640,480
// Until ESC pressed
WHILE TRUE
// Fade direction
IF dir=1 THEN INC a
IF dir=0 THEN DEC a
// Limit fade
IF a>95 THEN dir=0
IF a<5 THEN dir=1
// Fade by 'a' value
ALPHAMODE a/100
// Draw original grabbed image (at fade level a/100)
DRAWSPRITE 1,0,0
// Reset alphamode
ALPHAMODE 0
// Show a solid image end though background is fading
DRAWRECT 320,240,64,64,RGB(255,0,0)
SHOWSCREEN
WEND
Yeah, this is what I do already. Grab the screen before doing showscreen, and then fade that. It's just you must always remember to do that, and it isn't always that convenient. Sometimes you just get to a certain point and just want to fade whatever is currently on the screen without worrying to remember anything earlier. No big deal, just wondered if there is a way to do it. I've completed all fades a while back anyway, it's just something I thought might exist.
Cheers
Heh, I think I'm remembering that old STOS fade command that you just kicked off and it faded the screen. Was pretty simple, and you didn't have to care where ever you want to use it. No worries.
Right, as I said I've had this working for weeks really, I just thought I would mention it. Now back to something more interesting, like getting bluetooth working. Much more meaty...
Cheers
QuoteIt's just you must always remember to do that, and it isn't always that convenient.
Eh?
If you need to fade why would you forget? A routine such as that shown above is easy, fast and can conveniently be placed into a function.
Essentially my game screen is in a single routine, so it draws everything in there and then does a showscreen. My input routine is outside this and so when selecting an option you want to fade. Easy enough in that when I want to fade in this menu I call the game screen routine with a flag to now use showscreen, then call a fade routine, which firstly grabs the screen and uses it to fade out without actually being in the main routine. Once finished then the program goes to the next point (eg. a menu). Making the fade routine generic then I could use the grabsprite within the fade routine, but because of my bunging it together attitute when I first discovered GLB not all routines use the same draw screen routine. Obviously I could have coded it better from the beginning, and I will do from now on, but I was just wondering if there was an easy way to grab the frontbuffer without having to make sure all routines I wanted to fade out needed to grab the sprite or by making all these routines use a standard draw screen routine, and in this way keeping a fade routine nice and generic. ie. I am lazy. Although amusingly not that lazy as I did grab the screen before all fades, just I wondered about a front to back buffer copy to make it easier is all.
Cheers
QuoteI first discovered GLB not all routines use the same draw screen routine.
All images are drawn to the backbuffer, plain and simple - you don't need to know how they get there. They will draw in the order that your code asks it to, but you can change that draw value at any time (Z buffering is a good example, which adds distance to sprites, like in a 3D isometric game).
My example above shows that you don't need to fade everything and you can still keep features fully visible on the screen. You can do this to one sprite or a hundred. You can make the fade simultaneous or unique to each image.
GLBasic is far more powerful and capable than STOS. It's time to move onwards and upwards and use that power! :)
I meant I had a different subroutine for each section of the game. One for the main menu, one for options, one for level select, pause game, main game etc. So a generic fade couldn't just grab the current screen by calling the routine in question with a flag to not use the showscreen command (or at least to grab the screen as a sprite before it does). Of course it isn't that hard to do by making my screen drawing subroutines all into one (and use CASE for example to decide what to draw depending on where I am), or to make the fade routine know where I am and call the appropriate screen drawing routine. It's just at the time I remember thinking it would be easier to just grab the front buffer and use that to fade.
On a positive note the bluetooth routine is working. Whoop.
Maybe I'm just a bit tired. Stupid credit card accreditation routines all week have lowered my programming lazyness (or upped it depending on your viewpoint).... :S
Ah, c'mon, STOS was awesome back in the day. If only I could find my old Dungeon Master clone I wrote in Uni (while my more mathematical friend worked on raster routines in assembly and now unsurpringly is a programmer with EA near San Fransisco...)... Lately though I mainly mucked around with Dark Basic after knocking around with Div (used to love that) and Blitz. Overall though GLB, apart from the odd syntax quirk, is pretty good, and holding up well against the others.
Cheers
I was Div user too. It was a fantastic language. Were you a regular to Div Arena? What was your alias?
After Div I moved to BlitzBasic, Blitz3D and PlayBasic. Then on to BlitzMax and finally settled with GLBasic. I did give DarkBasic a try back in the day too, but it was way too slow for my liking with a horrible IDE and syntax.
As for STOS, I had an Amiga, so AMOS (Easy and then Professional) was more my cup of tea, but essentially the same. Ahhhh... Those were the days! :D
Yeah, I know. You are pretty legendary really. Yeah, pretty regular, with a gap of about 5 years. :) By the time that Div clone worked perfectly in Vista it was all a bit too late. Still I managed to revive an old Cybernoid effort I bunged together about a decade earlier so not all bad. Awesome language though... My Alias? Hmm, can't remember now. I either go by Crivens or Dazzag. Probably the Dazzag one. Recentlyish (about 3 years ago) I put a game up a bit like Robotron that you play using a webcam and 2 marker pens (or at least something that has 2 different colours) on the Retroremakes site. But apart from initial interest nobody really cared so I've been a bit quiet lately, especially after a DB MUD had next to no interest either. Must stop picking boring stuff... and actually finish something...
DB? You mean DBC or DBP? DBP is a lot better. Although to be honest I haven't done anything in that for a couple of years at least. When your day job is coding travel systems in Slough it's hard to get interest going in the evening :)
Ah, AMOS. Yeah, used to right have arguments with an Amiga friend in Uni (remember Amiga means girlfriend in Spanish or somesuch...). No line numbers if I remember rightly (STOS had them)? AMOS came after STOS so they had time to perfect things, so I was always on to a loser. Still my copies of the 3D plugin and compiler swung things a little! Sigh. Them sure were the days. Programming with fags and lots and lots of beer :) Erm, fags as in Ciggies incase anyone was wondering...
Cheers
A fade routine is just plain easy:
For a=-1 to -.05 step .05
Alphamode 0
Draw your stuff
Alphamode a
Drawrect 0,0,640,480,rgb(0,0,0)
Showscreen
Next
I had exactly the same code in mind when first reading this, but I think it needs to be a bit more complex than that, hence my example, especially since GRABSPRITE was mentioned.
Yep mine is pretty similar except uses the timer to make sure fades at the same rate on any device. My only thought was because you had to integrate it into the main routine itself then it's not so easy to do a simple fade with what was currently left on the screen. If I just branch off to a quick new menu for example then it's not so easy within the new menu code to initiate a fade. Obviously with a set draw subroutine (that decides what to draw based on the area of the game) or making the fade handle which subroutine to draw is all very well (so can grab screen before showscreen so can be used on background with a fade outside the loop that showed the screen in the first place) but it would be nice to not worry and just copy the frontbuffer to use in a fade.
Cheers