Hi folks,
There is BLACKSCREEN for automatically coloring the background black after each flip. Would be nice if there is something to set the background color to something else.
Thanks
Michael
Well you can USEASBMP (after selecting a bitmap every clear screen will draw that image) or DRAWRECT at the start of every loop.
I know I could do that, but it slows down the framerate, which you don't have enough on the IPhone.
In OpenGL(ES) there exist a glClearColor command for this.
Seriously? The framerate is affected by either of those? Just how shit is the iPhone? Both of these work without problem on GP2X and Wiz, which are technically inferior.
DRAWRECT!
You only need drawrect once to set the background color, then you use "USEASBMP" once and from that point the screen will be cleared to whatever was on the screen when you last called USEASBMP. It should not change the execution-speed of your game at all. (Unless the iPhone is even worse than I thought)
Quote from: Ian Price on 2010-Feb-14
Seriously? The framerate is affected by either of those? Just how shit is the iPhone? Both of these work without problem on GP2X and Wiz, which are technically inferior.
It's not shit! But as you can imagine yourself, drawing a 480x320 image each frame is some kind of overhead when you could get the same result with other functionality. Anyway, I just asked if something like this could be implemented.
We will see when the IPad will be available and someone will recomment drawing an 1024x768 image each frame. :D
There is only one recommending drawing the box each frame, did you try the other ideas at all?
Quote from: Moru on 2010-Feb-14
There is only one recommending drawing the box each frame, did you try the other ideas at all?
Moru, thanks for your suggestion. No, I didn't try it because I know the result would be the same like a BLACKSCREEN, just with a different color. My inital request was because drawing a rectangle or an image with all the state changes that might be involved internally will be slower than other possible implementations. Its not a must but a nice to have. So lets end here.
But it won't be slower. The USEASBMP command will change the black CLS to whatever bitmap or rectangle colour you choose. There will be NO impact on gamespeed. If you're getting 60FPS with just a showscreen now, you'd still get 60FPS when using USEASBMP before you're main loop.
You load or create an image and USEASBMP before your main loop, and that's it. All done. You never need to call it again.
So you are saying that BLACKSCREEN is basically a combination of drawing a black rectangle and USEASBMP?
Basicly yes. Try it and see if it does anything to the framerate on your target machine.
If it act the same, then it won't be slower.
If you use any backbuffer instead of BLACKSCREEN, you get a lower framerate on PC as well. Try on a slow netbook as I do, and you will see.
You're right. It totally sucks.
I'll make an optional parameter for the clear colour of BLACKSCREEN in a next update, OK?
Quote from: Kitty Hello on 2010-Feb-15
You're right. It totally sucks.
I'll make an optional parameter for the clear colour of BLACKSCREEN in a next update, OK?
Thanks. Does BlackScreen combine DrawRect and UseASBMP or does it do a ClearColor 0,0,0?
QuoteTry on a slow netbook as I do, and you will see.
Surely every GLBasic program is crap on a netbook? From my experience it is anyway.
Quote from: Kitty Hello on 2010-Feb-15
You're right. It totally sucks.
I'll make an optional parameter for the clear colour of BLACKSCREEN in a next update, OK?
I'd suggest keeping the language intuitive - if you can add an optional colour then make it a new command like CLEARSCREEN or something. A command with the name "BLACK" in it should not do other colours or else the language becomes confusing.
Quote from: Ocean on 2010-Feb-15
Quote from: Ian Price on 2010-Feb-15
Surely every GLBasic program is crap on a netbook? From my experience it is anyway.
That's a teaser I can't resist.... ;)
My project is developed for an Atom based board, that's why I develop and/or test/validate on a netbook which happens to have a similar configuration.
There's a bit of 3D going on (one or two objects only) the rest is 2D. The app shows real time measurement data in a graphical form. For this type of application, 60 fps is fast enough, the graphics hardware won't display more than that anyway...
It really works flawlessly; I get my required number of fps and can still reduce processor load to significantly below 10%, so there is still room for future application enhancements. The acquisition of measurement data is off-loaded to the second core by using Gernot's thread libraray, which for now I only use to handle serial communications. There's some other use for that thread library in the wings though...
Ocean
TBH I've only tested one program - which worked flawlessly on lesser machines (including Wiz and GP2X), so I couldn't understand why it was crap on a several types of netbooks (including a variety of supposedly shit-hot Samsungs (N110 - N130 or whatever they were)). I really should try my GLBasic games on my son's netbook and see how they perform, as other games work pretty well.
As for the CLEARSCREEN issue - another command would indeed be favourable, if required, rather than BLACKSCREEN.
Oh dear. Never touch anything ...
Changing the colour is no problem. It basically just does glClearColor.
But, if I change the name, the old code will no longer be valid. I could make a compiler warning "deprecated, use ... instead".
CLEARSCREEN might be the better name - even for the black screen.
Why not just leave BLACKSCREEN in and add CLEARSCREEN? If that's not possible then I vote for CLEARSCREEN.
CLEARSCREEN RGB(R,G,B) FTW.
CLEARSCREEN sounds good. I never used BLACKSCREEN :)
Since GLBasic does a fresh black screen on every frame I haven't realy seen a use for it except when playing around with lots of USEASBMP. CLEARSCREEN(rgb()) would be nice.
ok, it's clearscreen. And I leave blackscreen for compatibility a few releases still.
Woo! I named a GLBasic command!!! :enc:
:P
Great, here's your medal :))
[attachment deleted by admin]
*LOL* :D
awesome
NICE! :)
A suggestion: With a new CLEARSCREEN command, can there be the option to not clear the back buffer at all?
The reason I ask is that many applications will always completely cover the screen every frame so BLACKSCREEN or USEASBMP will needlessly use up precious CPU cycles.
useasbmp will not clear but use a bitmap instead of the clear. The clearscreen sets a colour to clear. You can't keep the current garbage, though if you want that. Use USEASBMP instead.
Kitty is correct. Clearing a screen using a bitmap is quite slow. Clearing the screen direct is much faster - no copy involved - just direct to memory - Does no-one remember $0a0000 and a bit of "rep stosw" back in the old days, or I am the last of the ASM coders???
lol, yes I remember something about the Mode 13 Magic, drawing directly to the video memory
Quote from: AMC on 2010-Aug-21
Kitty is correct. Clearing a screen using a bitmap is quite slow. Clearing the screen direct is much faster - no copy involved - just direct to memory - Does no-one remember $0a0000 and a bit of "rep stosw" back in the old days, or I am the last of the ASM coders???
Hmmm ... i remember the eighties:
PRINT CHR$(147)
That line was clearscreen on <3 COMMODORE 64 <3
poke 53280,0-15 changed BG colour on the C64
poke 53281,0-15 changed border colour on the C64
or visa versa ;)
and poke 646, colour for the text colour.
1024-2023 for the text screen
$C000-$CFFF for free 8K ram
$D000+ for sprites
$FFD2 for printing text
$FFF0 for moving the cursor
:)
Well, one step up on the computer ladder, still no protected memory area :-)
Atari ST:
move.l #$ff000000,$ffff9800.w ;Red background
Atari Falcon:
add.w #2,$ffff82a8.w ;lower Vertical Display Begin (moves screen 2 pixels down)
add.w #2,$ffff82aa.w ;lower Vertical Display End
Well actually I think you had to be in supervisor mode to do those but that wasn't more than a trap-call and done.
On a RISC OS machine, you would use SWI "OS_SpriteOp" for sprites, which in ARM assembler would be :
MOV R0,#2
SWI &2E
Quote from: Kitty Hello on 2010-Aug-25
and poke 646, colour for the text colour.
I actually still remember all of the c64 kernel, i/o, kernelstuff and mapped addresses of my head :)
Too bad out legacy on CSDb is just som crap mostly from temporary members: http://noname.c64.org/csdb/group/?id=671
poke 53272 + were the pokes for sound from my aging memory.. (I STILL have the C64 Programmers reference guide and use it occasionally on my C64 emulator ;) )
I have a few C64 programs that i wrote that i'd love to convert over but with all the peeks/pokes and printed special characters etc it would bew a nightmare
Quote from: BlueSteel on 2010-Aug-28
poke 53272 + were the pokes for sound from my aging memory.. (I STILL have the C64 Programmers reference guide and use it occasionally on my C64 emulator ;) )
I have a few C64 programs that i wrote that i'd love to convert over but with all the peeks/pokes and printed special characters etc it would bew a nightmare
I guess you have a typo (53272 x 54272)
53272 ($d018)= screen and charset pointer (hi/low nybbles).
54272-54230 ($D400 - $D41C) is the sound memory (sid mappings) - I wrote a musicplayer for c64 a few months ago :)
yup just a typo i'm full of them :( sorry
http://c64.manomio.com/ (http://c64.manomio.com/)