Messages

OS: Windows 7, Nvidia graphicscard (VSync locked to 60hz).

I still not sure what it happens, so I still experiment what it does.

I do set the LIMITFPS after the SETSCREEN (but still leave 60hz limit in options, now 120hz), and LimitFPS -1 is still somewhere better than LimitFPS 60 (not sure why???).

PS. LimitFPS 30 does still few framedrops, but nothing impact gameplay at all!

In the Options I set it to 60hz (which the graphics is locked too).

But if I set it to LimitFPS 60 in the code too, then the scroll is being skip a lots of frames, where its should been fluid (which look akward).

But in the other side, if I set it to LimitFPS -1, then its still set to 60fps limit (as I set that in the options), then its does it 100% fluid without framedrops or does that very very rare (all ok).

Also course that take a lots of cpu too (which is not a problem in a game my guess). Its might impact in a mobile phone thought, if I use LimitFPS -1 too?

Even If I set it to LimitFPS 30, its does jerky at time, but its not very noticable at all and complete playable.

So I dedicated to do 65 fps "update()" code (using system timer) and then do a separate "paint()". Something like this:

Code (glbasic) Select Expand


FUNCTION Run:
Delay=update_Delay(65)
run:
IF Delay>0
Controls() // controls only need to been updated once per frame.
FOR i=1 TO Delay
Update()
NEXT
ENDIF

Paint()
CLEARSCREEN -1
SHOWSCREEN
Delay=update_Delay()
IF KEY(1)=1 THEN END
GOTO run
ENDFUNCTION

FUNCTION  update_Delay: displayUpdateFreq=0
STATIC Fps
STATIC Timer#=GETTIMERALL()

IF displayUpdateFreq=0 THEN displayUpdateFreq=Fps
Fps#=displayUpdateFreq
LOCAL frames#, currentTimer#
    LOCAL maxDelay# = 1000 / displayUpdateFreq
    currentTimer#=GETTIMERALL()
    frames=(currentTimer#-Timer#)/maxDelay#
    IF frames<1 THEN RETURN 0
Timer=currentTimer
    RETURN INTEGER(frames)
ENDFUNCTION  // UPDATE_DELAY


So with above code, the  gameplay run 65fps, regaardless what LimitFPS is set to (65fps is set to avoid eventuelly jerky too).

So in that way I did go workaround the LimitFPS issues, but I do not sure what it happens if Vsync is forced disabled (and using LimitFPS -1)? I still want double buffer, even it might draw insanly fast...

I dont use clearscreen at all for the main drawings of the backgrounds.

But I doing drawing sprites using pngs with alpha, and I drawing them to a offscreen screen (USESCREEN 2). This is for avoid eventuelly seams artifact when scaled down.

This is not a option of course for the backbuffer, but its would been very neat to do that on offscreen screens aswell.

etc doing someting like CLEARSCREEN -2 for no color wipeout? (howover -1 could do that IF used other than screen 0).


I tried using CREATESCREEN in each frame, but is painfully slow....

Code (glbasic) Select Expand


LOCAL frame, animframe, w, h
USESCREEN 2
frame=imageGet("Game")
GETSPRITESIZE frame, w, h
CREATESCREEN 2, frame, w, h
animframe=imageGet("tiles")
USESCREEN 2
DrawMap(animframe, scr_X, 40, 0, 0, w, h)


hehe, but would been nice to see a official version of it on the same command.

Also then there is little but uncorrect, since its state its only works for iPhone for now, buts..... Due Palm Pre, I do still might design WebOS as both single and multiple mices.

I just for fun tried to plugin 2 mice into my computer for testing GETMOUSECOUNT() to work in Windows 7, but its still only found one? I think its just a litle limit, rather than a bug, since its not added currectly to Windws as stated in help file, but wrote about here to avoid forgetting it.

Also does Palm not support multitouch too and workable? if yes, the help file is somewhere unprecision.

I do seen multiply mices to work in other Windwos OS too, but Windows 7 is most important me think.

PS. Even older sysetems, MAME (A arcade emulator) could found more than one mices.

Smartphone is already used for wince without touchscreen.

This can been fooled when webos have touchscreen.

So much better to just tell which platform it's is on.

Screensize can already been detected by using desktop resoulution....

it's more how to detect controllers for android as well.

So webos is more smart to been used.

hmm, WEBOS of course for device and ANDROID for androids?

SMARTPHONE should really been removed that dont give any means anymore (its returned if no touchscreen is detected.... why?).

This due Android might have variered form for touch as well physical controls (Some have keypad, other keyboard, some game controllers). So I think its better to use a own info, like "CONTROLS" to detect that. If you add "CONTROL" info for that, SMARTPHONES is not required anymore, but can been kept as backward compatible.

Also bear in mind, Some Android Phones that support multi touch have a axis flip issues and hence its should not been used if you ask me, or warn about it.

Code (glbasic) Select Expand


FUNCTION PaintImage: Name$, x#, y#, alpha#, zoom#, xspot, yspot, yy#
LOCAL h#, w#, img, hh#, ww#, xx#, yy#
x=20
y=20
xspot=1
yspot=1
IF alpha#=0 THEN RETURN
IF Name$=0
// img=GetStr$(Name$, "Sprites") ' Just a name based sprite function rather than number. Not need for test here at all.
ELSE
img=Name$
ENDIF
GETSPRITESIZE img, w, h

// rect maths <- This code math the box where the sprite should been placement
// That one works perfecty as its should. I does this because I might later using scaling#
// (different than zoom, which was FOR resolution scaling).
IF xspot=-1 THEN PX=x#
IF xspot=0 THEN PX=ScreenWidth/2.0-(w#*zoom#/2.0)+x#
IF xspot=1 THEN PX=ScreenWidth-w#*zoom#-x#*zoom#

IF yspot=-1 THEN PY=y#
IF yspot=0 THEN PY=ScreenHeight/2.0-(h*zoom#/2.0)+y#
IF yspot=1 THEN PY=ScreenHeight-h#*zoom#-y#*zoom#
PW=w*zoom#
PH=h*zoom#

// test box using drawrect, where the sprite should been draw directly over.
ALPHAMODE 0.2
DRAWRECT PX, PY, PW, PH, RGB(255, 255, 255)

// some alpha code in that way I prefer. Not a issue in the real alphamode, its just me :-D
IF alpha#>0
alpha#=0-alpha#
ELSE
alpha#=-alpha#
ENDIF
ALPHAMODE alpha#

// draw a sprite top on the drawrect box, but its slighty off. Also some rotation support, not finished, but dont think about it.
SELECT ROTATE
CASE 180
PX=ScreenWidth-PX-PW
PY=ScreenHeight-PY-PH
CASE 0
ZOOMSPRITE img, PX#-((1-zoom#)*w#)/2, PY#-((1-zoom#)*h#)/2, PW#/w#, PH#/h#
DEFAULT
ENDSELECT
ENDFUNCTION


Tried it, seen its works.

Its was somewhere the only one I diddent tried out (1-zoom#). So close :-D.

The only issue is its still sometimes off with one pixel, which should been gone with a real top/left hotspot to avoid that, but elsewise thanks.

After trying to math how to math a sprite, based on topleft, center or rightcenter hotsots after about 10-15 hours, then I gave up.

Is is possible to change the hotspot on zoomsprite as well other sprite commands to set on the top left, which would been LOTS easier to math the placement of them? Something a missing command?

Here is the funtion I try to create. The box draw perfect, but zoomsprite is the issue, its not setting on the box as it should:

Code (glbasic) Select Expand


FUNCTION PaintImage: Name$, x#, y#, alpha#, zoom#, xspot, yspot, yy#
zoom#=0.5
x=0
y=0
xspot=1
yspot=-1
IF alpha#=0 THEN RETURN
IF alpha#>0
alpha#=0-alpha#
ELSE
alpha#=-alpha#
ENDIF
LOCAL h#, w#, z#
LOCAL img, hh#, ww#
IF alpha#<>0 THEN ALPHAMODE alpha#
IF Name$=0
img=GetStr$(Name$, "Sprites")
ELSE
img=Name$
ENDIF
GETSPRITESIZE img, w, h

// rect maths
IF xspot=-1 THEN PX=x#
IF xspot=0 THEN PX=ScreenWidth/2.0-(w#*zoom#/2.0)+x#
IF xspot=1 THEN PX=ScreenWidth-w#*zoom#-x#*zoom#

IF yspot=-1 THEN PY=y#
IF yspot=0 THEN PY=ScreenHeight/2.0-(h*zoom#/2.0)+y#
IF yspot=1 THEN PY=ScreenHeight-h#*zoom#-y#*zoom#
PW=w*zoom#
PH=h*zoom#

// ALPHAMODE 0.2
DRAWRECT PX, PY, PW, PH, RGB(255, 255, 255)


SELECT ROTATE
CASE 180
PX=ScreenWidth-PX-PW
PY=ScreenHeight-PY-PH
CASE 0
ZOOMSPRITE img, PX, PY, zoom#, zoom#
DEFAULT
ENDSELECT
ENDFUNCTION


I use this for scaling graphics for any resolutions.

PS. I use name rather than number for ease programmering, so you can coomand the getspr$ out without issue.

PPS. YY# does nothing at all, and is just a placeholder to been removed later.

I have to ask:

1. Does this also happens with none transparency png, using pink (etc 8bit png instead of 24bit)?
2. How about using a real alpha png, rather than a transparency color?

Those could been used for col checks only.

[Some thing I have to ask:]

Cool. I have planned to wait to App Game Kit, because its validared ot came to Android too, but the language is still not on market. This post cause me to just start on Gl-Basic again, where I planning and starting a new game.

So even I is a die hard iOS user, congratulations, and I hope to see this out too, so I can port it so many mobiles as possible.

Some thing I have to ask:
1. Possible to detect controllers the phone might have, since some phones might have physical controllers (keypad and keyboard)?
2. Touchpad support for Sony Ericsson Xperia Play could been cool, but not required (using the analog joy commands of course). That phone is a very cool Android phone I have seen (My friend have that one).
3. Why not Android v2.1 support. Its have OpenGL and all, so its should been possible to run GlBasic nicely, I guess they threat somewhere like a older iPhone. Android 1.xx is a nogo of course. Howover not important throught.

Something I noticed:
A. Remember there is some bad multitouch screens as well, when you cross 2 fingers in a line, then it goes very bad. Remeber design with that in mind, or possible to disable multitouch (in the game of course).

First at all, its common to use compressed format today and have been done that in years. Why does GlBasic still only use PCM-WAV? Its take a lots os hardrive space for a download game, when using many sfx.

for me even ADPCM-Wav format would been much better choice, which is a nice SFX format, even its a pretty old format. Its still a good SFX format, that dont use so much memory as PCM-WAV does.... And for systems, that cant play native that format, could jus uncrompress in load time.

That for is that I have used in years. Ogg would also been nice to been supported for systems that native support it for Music (patent crap), elsewise its should return a error (same with other music formats, like m4a). Howover its not a issue normallt for phones, since carriers allreadt have paid for that (as I aware at).

there is also a missing for a PAUSESOUND() and RESUMESOUND().

Also its would been nice to checkout where the music position is and also to play move the position in the music file, if possible.

I might came with more ideas for better sound commands, since they are really basic right now (but does works, which is important).

the code its self works as it should.

This is just do I wanted to automatic load the files with might have varied length of animations.

I now use this:

Code (glbasic) Select Expand


FOR r=1 TO MAXANIMHEADS
FOR i=1 TO 10
t=r*10+i-1
A$="headtile_"+r+"_"+i+".png"
IF DOESFILEEXIST(A$)=1
DEBUG A$+" "+t+"\n"
LOADSPRITE A$, t
ELSE
BREAK
ENDIF
NEXT
NEXT


In the old code, I loaded the sprite regaardless the file was exists or not, then use BREAK when the size of sprite was zero. The code elsewise ran fine, but just jump into the GETSPRITESIZE command (after the LOAD command)after the app exists....

PS. Im are aware of the GENSPRITE(), but is not required in this app.

how do I detect if a sprite exists or not, whithout the editor jump to that line on exists... which is pretty annoyring.

I use something like this:

GETSPRITESIZE t, XX, YY

And if XX is 0, I asume there is no sprite here and do some code here.

If a do its on a TRY command, the editor just annoyring jump there instead.

I hate when the editor jump to these commands on exists, so I need to scroll where I was code every time, when I known there is no bug here......

I need to find a with to detect if a sprite exists or not WITHOUT these annoyring jumps.

PS. It might have caused by LOADSPRITE when no file found, but I dont think that is a issue, but using DOESFILEEXIST now instead to avoid that editor jump.

values between 0.0 and 1.0 works as it should, but values between -1.0 and 0 works very odd and can been very confuction to been used the right way.

By now -1 and 0 is the same, but -1 should been blank and not a value close to 0. Its simply seen the command do the other way as its should.

Normally 0 should been the middle point, so 0 is normal, -1 is completly off and 1 is lightest.

This would been much easier to understand.

PS. I known there is a workaround by creating a SETALPHAMODE function and do the math here, but for me its still a bug.