Gernot, what have you done with the IDE???? I cannot now use the down arrow key!!!!! All other arrow keys work fine.
Ach. Was just about to settle down to a good afternoon of GLB too! Is there a way to backout a GLB upgrade? Otherwise will have to switch to the laptop which is a touch annoying...
Fast upgrade soon maybe? :)
Cheers
Also just noticed that the files list can use the down key but not the up key. Erm...
Plus the down key in the keypad (numlock off) doesn't work either in the code editor.
Cheers
Yes,. down arrow key is a blorked...
The zip file created could be used to go back a version...
Something else I noticed while testing is when I am using CREATESCREEN/USESCREEN.
Basically I use createscreen and then usescreen. The user can select to clear the usescreen and I use drawrect to do that. Yesterday that was fine and it blacked out the usescreen. Now though it doesn't work.
Interestingly when I blank the usescreen with drawrect it gets rid of anything drawn to the usescreen since the createscreen. But keeps the original background. Something like that. Either way if I use clearscreen before the createscreen then using drawrect to black it all out does actually work again. Possibly because my old screen had not been drawn with showscreen before I used createscreen. So a showscreen should work before a createscreen too?... Yes that's true. So now createscreen takes whatever is in the backbuffer and uses that as a backdrop that isn't part of the main screen?
Is an interesting side effect though. My routine was like a paint drawing function. Without clearing the screen then it looks like you can draw directly onto the background picture and if you save the image it does not include the background picture. A bit like layers in a paint package. And then you can take what's drawn and place it over a different background picture. Nice. Something to remember for the future I'm sure...
Don't call it a bug then, but rather an interesting new feature to know about incase anyone is also confused in the future.
Cheers
Down-key and update warnings are serious. I'll fix ASAP. Tonight.
The CREATESCREEEN should make a screen that is black + transparent. Does it contain parts of the back buffer? That would be a bug then. Use drawrect to be safe.
Cool.
Yeah it contains the back buffer. My createscreen is smaller than the actual screen if it helps. Interesting, I just tested it again and it isn't blacking it out. I used showscreen and clearscreen first just incase... I'll change back to just the clearscreen before the createscreen...
Strange that works again:-
cscreen=GENSPRITE()
//SHOWSCREEN
CLEARSCREEN 0 //Make sure all is blanked out otherwise createscreen may copy from background and use it as transparent layer
CREATESCREEN 0,cscreen,targetx/2,(targety/2)/3 //Make it a small window so is faster on higher resolution screensBut if you unrem the showscreen it doesn't blank out the createscreen. Pretty sure it worked with showscreen unremmed and clearscreen remmed though... Yep just tested and that is true too. Just doesn't work with showscreen and clearscreen before the createscreen. Strange eh? Plus rem showscreen and clearscreen and it doesn't work there either... Not very logical..
Careful though as that one is actually quite a good feature if we can control it. Make it like the last version and have it completely black as default, but add a new optional parameter to createscreen to make it use the backbuffer as somesort of transparent layer then that would be cool. As I said it has benefits that I can't think how to program easily to allow a quick FPS. I mean my routine is similar to your scribble routine (sort of) and works well speed wise on any resolution it seems. But maybe I will change to have a different background for the paint routine. Then when it saves the usescreen sprite it only saves what you have drawn, not the background (which is what the error is doing). Nice...
Cheers
Ignore me. This has weird results. The code below works every time, but when it goes back into it for a second time it doesn't clear at all, even though I use a loadsprite "",cscreen at the end of the routine.
Best bet is just to get it back to how it was yesterday before 10.203.
Cheers
It's taught me how much I use the down key when I'm editing!
Copying EditorE.exe from the backup zip file and overwriting the one in the install folder has given me a temporary fix for the time being.
Ah ang on, the createscreen is even more interesting. I'm now on my laptop using Win7 and GLB 10.191.
Strangely now the above code (showscreen remmed out and clearscreen being used before createscreen) causes the same bug as 10.203 without the clearscreen or showscreen. ie. the usescreen is not blank but has the background of the backbuffer. And cannot be removed. It's like it's the default "black" background. Do a drawrect on the screen and it blanks out everything else that was drawn to the usescreen since the createscreen. Just not the default "black" background which remember is what was on the screen originally.
If I remove the clearscreen (so is just createscreen) on 10.191 then it works as it did yesterday! ie. black background to the createscreen. But then if I go back to the routine in the same session it will produce the same bug as above! WTF?
Seriously strange stuff here. Surely a createscreen should be like a brand new screen with just black as the backdrop? Fair enough if have an option for a background graphic that stays there even if the screen is blanked (and won't exist if save the sprite as the current bug does currently), but the default action needs to be 100%.
Cheers
GLB 10.205 fixes the cursor key problem and my createscreen problem is back to how it was yesterday.
So basically I use gensprite then createscreen (with screen 0) to get a black smaller than screen sized rectange, and draw to that. When the routine is finished I loadsprite "" with the createscreen sprite to remove it from memory. When the routine is called in the future (on the same session) then I get the bug where the backbuffer is copied to the createscreen (either that or all the pixels are transparent) and the area I draw to is not black (is the same as the actual graphics underneath it) but when I savesprite the screen it only saves the drawn graphics since the createscreen (ie. like it's supposed to be with black background).
Cheers
Might be worth using CREATESCREEN with a size of 0,0 as well as deleting the associated sprite.
I tried that at the end of the routine and with 1,1 but both don't make any difference.
Here is the code at the end of the function:-
SAVESPRITE docdir$+"/high"+painthigh+".png",cscreen
CREATESCREEN 0,cscreen,0,0 //Make sure resizes so clears out created screen
LOADSPRITE "",cscreen //Clear out memory
USESCREEN -1
Cheers
Post a standalone example please?
Easier said than done really. Will try and get something together tomorrow.
For a summary though in a sub-file I have a function where I use screen 0 with createscreen and create a screen the width of the device and a third the height. Obviously I then usescreen to draw everything to it. With 10.205 this nicely blacks out what is underneath (a 3DES created backdrop) when I stretchsprite the created screen onto the proper screen. At the end of the routine I loadsprite "" with the createscreen sprite, and as mentioned above use createscreen again (although makes no difference if I do this or not) with screen 0 at a size of 0,0 to see if that resets screen 0.
Next time I enter the routine (in the same run) it obviously uses createscreen again on screen 0, but this time it does not black out what is underneath. It is basically transparent. Although everything else is fine with what is drawn to screen 0 using usescreen and it even savesprites perfectly fine (including the transparent bits being black as they should be in this case).
Cheers
Note that I realised in a CPU intensive routine that using 3DES in the middle of it is probably a bit of a mistake even though it's pretty fine on most things, so I've replaced the 3DES bit by a screen grab (createscreen with screen 1) of what was going on with the 3DES (doesn't move at that stage anyhow) and paste this instead of using 3DES. Doesn't make a difference to the bug although I thought I'd mention it to exclude the 3DES, plus it gets a few more FPS I would imagine.
Cheers
Rats. Trying to make a sample project using just the drawing routine and oh happy days it works just fine. Seriously annoying. Right back to see what the hell is going on...
Cheers
I give up. Must be a lot of stuff I do in the main routine. Strange problem that I would have thought would not come up (createscreen in a function), but sod it can't be bothered mucking around seeing what is going on. I'm thinking it might be alphamode related (I do a lot of mucking around with it) but I dunno. Will ignore for now methinks as I made a work around that suits me just fine.
Cheers
Its always annoying when a routine only causes problems with complicated code :)
Yeah. Really can't see why it would do it though. Best guess is something is messing with the alphamode (I do a lot in my game but not at all in my example code), even though I cannot set it to something useful when I draw it. Perhaps need to set it properly when use createscreen? Strange thing is if I then savesprite it loads it in fine with black instead of transparent pixels when I show the highscore chart.
Nevermind, the workaround is fine. When grabbing the 3D screen as a sprite to speed up the background drawing then I just make sure to include the black rectangle before I finish grabbing the screen. So when I draw the background it includes the black rectangle anyway. I'm thinking then that the problem is with transparent pixels in a createscreen as it does not overwrite this with data from the original screen which was there (maybe even though I clearscreen it etc) when the createscreen was made originally.
Still over the years I've had a load of these unexplained ones and I've always done a workaround. Good enough.
Now to get on and finish the damn thing for the app store! No, ang on, mate coming around for drinks. To the app store after lots of beer (ahem and a few more days of ironing out bugs and inserting things like help screens and credits...)!!!
Cheers
Another Bug in V10.205:
If I compile for Linux the first time, distribution folder gets created with project.linux file inside it. But the file name only contains small letters instead of caps+small letters, like its intended.
If I compile for Linux the second time, it does not replace the project.linux file in the distribution folder, instead it creates a Project.linux file in the app folder. This time it keeps the name like intended.
3rd, 4th... etc. compile just replaces the Project.linux file in app folder, ignoring the distribute folder.
Btw I dont like the idea of the distribution folder (especially for the big platforms), I was just fine with the old way of compiling for Linux, but I understand, why other find that useful.
When compiling for linux for the first time, I had :
, not found (try using -rpath or -rpath-link)
I dont get your strangeness with the filename changing though - it's always lower-case here.