I'm not suggesting a generic method, I'm suggesting a return code per load/creation statement. Yes, I'm aware that they would have to be individually coded on the back end, and yes, I think the amount of effort is warranted. It doesn't look very professional for your program to crash when it could instead give the user a useful error message.
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
#2
IDE/Syntax / Error Handling
2013-Jun-02
Can we please have error checking? You should be able to check the return code on commands like LoadSprite for example to gracefully handle if they fail rather than having your program die unexpectedly.
#3
GLBasic - en / Re: Windows 8
2012-Oct-29
Has anyone upgraded to the Windows 8 production release and tried GLBasic / GLBasic apps on it??
#4
It seems like running a programming course using GLB is a common idea! I've only gotten as far as thinking about it though.
My thoughts ...
BigSofty hit the nail on the head - entertain first, educate second. No one (child or adult) is going to want to sit through Hello World type exercises for very long in short term course - they want to learn to write games and they want to learn to write them yesterday. So show them a game, then break it down so when you talk about something like a loop or an array they see why they're important.
The way I thought of doing it would be to do something like
1) Show them pacman
2) Show them a cut down version which is only a corridor. Animate a ghost moving down it - use that to show what a loop is. Change the length of the loop / the step value etc to demonstrate how they affect the ghost's movement
3) Show a map where every square has food in it, then one with half of the map with food in it etc, cut to the code that shows 1s and 0s in an array to show where the food ends up. Manipulate values in real time to show it changing the food placement in the level - use that to explain arrays.
4) Show pacman moving without any map. Use it to demonstrate how the keyboard input / switch statement works.
etc.
Each time you show them something you're showing something tangible in an "exciting" game, and straight away relating it to the code so they understand the theory. You also modify the code and show what that does to your "game" to reinforce the theory. It'll sink in a lot more than just reading them the theory off a slide.
Once they understand the basic theories and have seen them applied in a real (and INTERESTING!) game scenario, then get them to start writing their own version of naughts and crosses etc.
Kids will be hard to interest if you start with monochrome type games / text adventures, they want to get hooked by something with colourful graphics that's fun. I think if you start with "the basics" from a book/slide and don't show them a practical and fun "game" application for the theories until a few lessons later, they will already have not paid enough attention and the theories won't have sunk in.
Keep the interest alive by letting them do things like compile their own android version of their naughts and crosses game (provide them fun graphics to use instead of just a circle and a cross - take their photo and use that instead, and use yours for the AI for example). This way they can take something home at the end of the lesson that they can show to their friends and say "look what I made!" The most exciting thing about any course you do is to be able to tell/show everyone else.
The biggest problem I came across while planning a course was where to get enough pre-made graphics and sounds so you don't lose 90% of your lesson time having the students trying to draw something.
Lastly, have some contingency plans. You might find that either you finish all your lessons a few weeks early, or you're a few weeks behind, so know what you'll do if these sorts of things happen. Also, what will you do when someone's sick for a week then doesn't understand what you're teaching when they show up the next week?
Hope that's useful!
My thoughts ...
BigSofty hit the nail on the head - entertain first, educate second. No one (child or adult) is going to want to sit through Hello World type exercises for very long in short term course - they want to learn to write games and they want to learn to write them yesterday. So show them a game, then break it down so when you talk about something like a loop or an array they see why they're important.
The way I thought of doing it would be to do something like
1) Show them pacman
2) Show them a cut down version which is only a corridor. Animate a ghost moving down it - use that to show what a loop is. Change the length of the loop / the step value etc to demonstrate how they affect the ghost's movement
3) Show a map where every square has food in it, then one with half of the map with food in it etc, cut to the code that shows 1s and 0s in an array to show where the food ends up. Manipulate values in real time to show it changing the food placement in the level - use that to explain arrays.
4) Show pacman moving without any map. Use it to demonstrate how the keyboard input / switch statement works.
etc.
Each time you show them something you're showing something tangible in an "exciting" game, and straight away relating it to the code so they understand the theory. You also modify the code and show what that does to your "game" to reinforce the theory. It'll sink in a lot more than just reading them the theory off a slide.
Once they understand the basic theories and have seen them applied in a real (and INTERESTING!) game scenario, then get them to start writing their own version of naughts and crosses etc.
Kids will be hard to interest if you start with monochrome type games / text adventures, they want to get hooked by something with colourful graphics that's fun. I think if you start with "the basics" from a book/slide and don't show them a practical and fun "game" application for the theories until a few lessons later, they will already have not paid enough attention and the theories won't have sunk in.
Keep the interest alive by letting them do things like compile their own android version of their naughts and crosses game (provide them fun graphics to use instead of just a circle and a cross - take their photo and use that instead, and use yours for the AI for example). This way they can take something home at the end of the lesson that they can show to their friends and say "look what I made!" The most exciting thing about any course you do is to be able to tell/show everyone else.
The biggest problem I came across while planning a course was where to get enough pre-made graphics and sounds so you don't lose 90% of your lesson time having the students trying to draw something.
Lastly, have some contingency plans. You might find that either you finish all your lessons a few weeks early, or you're a few weeks behind, so know what you'll do if these sorts of things happen. Also, what will you do when someone's sick for a week then doesn't understand what you're teaching when they show up the next week?
Hope that's useful!
#5
Quote from: Crivens on 2012-Aug-21I've been looking for that post for the last hour and can't find it (that's how I found this thread).
Also didn't Gernot, quite a while back, have a solution for GLB that would allow iDevice compilation from a Windows PC? If I remember rightly he couldn't get it working for actually fully publishing to the App store, but it did work for just getting it on your iDevice. Really should get that out the door as it's still a *very* useful tool that as far as I know no other SDK supports.
Can someone definitively confirm whether I can compile directly to an iphone without a mac at this point? I've just had a requirement to write an iphone app, don't have a mac, and remembered that Gernot said something about a way to do it. For the life of me I can't find the thread, and all posts saying I definately need a mac seem to be about 3 years old from when the licensing restrictions didn't allow the libraries etc to be used on a pc.
#6
Off Topic / Re: Maths help for my game
2012-Jul-05
Thanks guys, both for the help and the corrections!
I'll give it a go tonight and see if I can get it to work.
Cheers!
I'll give it a go tonight and see if I can get it to work.
Cheers!
#7
Off Topic / Maths help for my game
2012-Jul-04
Any takers on how to apply a sin wave on a vector?
Ie. Normally if your object was travelling down the screen you'd just add the sin value to your X coordinate, but what if you're not travelling horizontally or vertically?
I know I need to add the sin wave to the perpendicular of the vector, but I'm having trouble finding the formula written down without being in complicated maths language or expressed as a matrix.
So far I have
1) To work out coordinates based on an angle : x=cos (angle) and y=sin(angle)
2) Angle of a vector : angle=atan(ydifference,x difference)
(Where ydifference is your destination coordinate - your current coordinate)
Any takers?
Bonus points if you can explain to me why in code that uses trigonometry you see the code "normalize" the vectors all the time. What does the normalizing do? I think it just maps it to the unit circle (ie. range -1 to +1) - is that right?
Ie. Normally if your object was travelling down the screen you'd just add the sin value to your X coordinate, but what if you're not travelling horizontally or vertically?
I know I need to add the sin wave to the perpendicular of the vector, but I'm having trouble finding the formula written down without being in complicated maths language or expressed as a matrix.
So far I have
1) To work out coordinates based on an angle : x=cos (angle) and y=sin(angle)
2) Angle of a vector : angle=atan(ydifference,x difference)
(Where ydifference is your destination coordinate - your current coordinate)
Any takers?
Bonus points if you can explain to me why in code that uses trigonometry you see the code "normalize" the vectors all the time. What does the normalizing do? I think it just maps it to the unit circle (ie. range -1 to +1) - is that right?
#8
Bug Reports / Re: MOUSEAXIS(0) and 1 inside X_MAKE3D
2012-Jun-29
I originally had commented the MOUSESTATE command as I was only interested in watching the numbers. I put it back in to make the camera rotate - it's quicker to tell how well the mouse is being read by watching its results modify the 3D world than watching the numbers. It can be commented out and I still have MOUSEAXIS broken.
I get a lot more reliable results with the MOUSEAXIS commands next to the SHOWSCREEN, if they are at the top tgeb the results are a very intermittent (ie. exactly what MrTAToad raised originally).
Thanks for testing! It would be interesting to see if other people find it broken or working on their systems as its results are definately very unreliable for me. (I'm also going to assume you're testing on Windows as if you're testing on another platform you might be getting different behaviour).
I get a lot more reliable results with the MOUSEAXIS commands next to the SHOWSCREEN, if they are at the top tgeb the results are a very intermittent (ie. exactly what MrTAToad raised originally).
Thanks for testing! It would be interesting to see if other people find it broken or working on their systems as its results are definately very unreliable for me. (I'm also going to assume you're testing on Windows as if you're testing on another platform you might be getting different behaviour).
#9
Bug Reports / Re: MOUSEAXIS(0) and 1 inside X_MAKE3D
2012-Jun-29
Here's the 6DOF camera code from the forums. I've moved the variable declarations/functions around to make it compile, and changed the values shown on the screen slightly to display mouseaxis results.
Watch the figures returned by mouseaxis and tell me if it consistently reflects what you're doing with the mouse. If it does, you're getting different results to me. I get numbers sometimes, 0 other times (when I should be getting mouse movement values). Compare the difference if you use the mouseaxis near the top of the main routine against using the mouseaxis calls right before showscreen command. They SHOULD behave the same but they don't and therefore it's a bug as where it's called from in relation to X_MAKE3D, X_MAKE2D and SHOWSCREEN, should not impact the values returned!
Use the mouse buttons and see if it always changes the camera rotation like it should - it's inconsistent for me. (Note that the original code divided the mouseaxis returned values by 10, I took that out to really show when it was and wasn't working.)
Prove me wrong that MOUSEAXIS ISN'T broken!
Watch the figures returned by mouseaxis and tell me if it consistently reflects what you're doing with the mouse. If it does, you're getting different results to me. I get numbers sometimes, 0 other times (when I should be getting mouse movement values). Compare the difference if you use the mouseaxis near the top of the main routine against using the mouseaxis calls right before showscreen command. They SHOULD behave the same but they don't and therefore it's a bug as where it's called from in relation to X_MAKE3D, X_MAKE2D and SHOWSCREEN, should not impact the values returned!
Use the mouse buttons and see if it always changes the camera rotation like it should - it's inconsistent for me. (Note that the original code divided the mouseaxis returned values by 10, I took that out to really show when it was and wasn't working.)
Prove me wrong that MOUSEAXIS ISN'T broken!
Code (glbasic) Select
// --------------------------------- //
// Project: 6DOFCam_lib
// Start: Thursday, November 19, 2009
// IDE Version: 7.177
//
CONSTANT rad = 3.1415926535/180
TYPE Tquaternion
w#
x#
y#
z#
ENDTYPE
TYPE Tcamera
//position
x#
y#
z#
//look vector
lx#
ly#
lz#
//up vector
ux#
uy#
uz#
//right vector
rx#
ry#
rz#
FOV#
aspect#
nearClip#
farClip#
ENDTYPE
LOCAL cam1 AS Tcamera
LOCAL speed# = .01
LOCAL xv#, yv#, zv#, p#=0, r#=0, y#=0
LOCAL mx%, my%, mw%, mba%, mbb%
// --------------------------------- //
// Project: 6DOFCam_test
// Start: Thursday, November 19, 2009
// IDE Version: 7.177
cam1.x# = 0
cam1.y = 0
cam1.z = 0
cam1.lx = 0
cam1.ly = 0
cam1.lz = -1
cam1.ux# = 0
cam1.uy# = 1
cam1.uz# = 0
cam1.rx = 1
cam1.ry = 0
cam1.rz = 0
cam1.FOV = 45
cam1.aspect = 1024/768
cam1.nearClip = .01
cam1.farClip = 5000
WHILE TRUE
MOUSESTATE mx, my, mba, mbb
mx = MOUSEAXIS(0)
my = -MOUSEAXIS(1)
X_6DOFCAMERA(cam1)
//Linear Velocity Dampening (SPACE)
IF KEY(57)
xv = xv * .95
yv = yv * .95
zv = zv * .95
ENDIF
//Angular Velocity Dampening (CTRL)
IF KEY(29)
r = r * .95
p = p * .95
y = y * .95
ENDIF
//Accelerate Forward (W)
IF KEY(17)
xv = xv + (cam1.lx - cam1.x) * speed
yv = yv + (cam1.ly - cam1.y) * speed
zv = zv + (cam1.lz - cam1.z) * speed
ENDIF
//Accelerate Backward (S)
IF KEY(31)
xv = xv - (cam1.lx - cam1.x) * speed
yv = yv - (cam1.ly - cam1.y) * speed
zv = zv - (cam1.lz - cam1.z) * speed
ENDIF
//Accelerate Left (A)
IF KEY(30)
xv = xv + (cam1.rx - cam1.x) * speed
yv = yv + (cam1.ry - cam1.y) * speed
zv = zv + (cam1.rz - cam1.z) * speed
ENDIF
//Accelerate Right (D)
IF KEY(32)
xv = xv - (cam1.rx - cam1.x) * speed
yv = yv - (cam1.ry - cam1.y) * speed
zv = zv - (cam1.rz - cam1.z) * speed
ENDIF
//Accelerate Down (F)
IF KEY(33)
xv = xv + (cam1.ux - cam1.x) * speed
yv = yv + (cam1.uy - cam1.y) * speed
zv = zv + (cam1.uz - cam1.z) * speed
ENDIF
//Accelerate Up (R)
IF KEY(19)
xv = xv - (cam1.ux - cam1.x) * speed
yv = yv - (cam1.uy - cam1.y) * speed
zv = zv - (cam1.uz - cam1.z) * speed
ENDIF
// change IF the left mouse button is pressed
IF mba = 1
//Pitch mouse up AND
p = p + my
//Yaw
y = y + mx
ELSEIF mbb = 1
//Roll with right mouse button
r = r + mx
ENDIF
cam1.x = cam1.x + xv
cam1.y = cam1.y + yv
cam1.z = cam1.z + zv
cam1.lx = cam1.lx + xv
cam1.ly = cam1.ly + yv
cam1.lz = cam1.lz + zv
cam1.rx = cam1.rx + xv
cam1.ry = cam1.ry + yv
cam1.rz = cam1.rz + zv
cam1.ux = cam1.ux + xv
cam1.uy = cam1.uy + yv
cam1.uz = cam1.uz + zv
debug_view(0,0,0,100,RGB(255,255,0),RGB(255,0,255),RGB(0,255,255))
camera_roll(cam1,r)
camera_pitch(cam1,p)
camera_yaw(cam1,y)
X_MAKE2D
PRINT "mx = "+mx,10,90
PRINT "my = "+my,10,100
PRINT "Cam Pitch = "+p,10,110
PRINT "Cam Yaw = "+y,10,120
PRINT "Cam Roll = "+r,10,130
// mx = MOUSEAXIS(0)
// my = -MOUSEAXIS(1)
SHOWSCREEN
WEND
FUNCTION quaternion_normalize AS Tquaternion: tmpQ AS Tquaternion
LOCAL mag# = SQR(tmpQ.w*tmpQ.w+tmpQ.x*tmpQ.x+tmpQ.y*tmpQ.y+tmpQ.z*tmpQ.z)
LOCAL q AS Tquaternion
q.w = tmpQ.w / mag
q.x = tmpQ.x / mag
q.y = tmpQ.y / mag
q.z = tmpQ.z / mag
RETURN q
ENDFUNCTION
FUNCTION quaternion_conj AS Tquaternion: tmpQ AS Tquaternion
LOCAL q AS Tquaternion
q.w = -tmpQ.w
q.x = -tmpQ.x
q.y = -tmpQ.y
q.z = -tmpQ.z
RETURN q
ENDFUNCTION
FUNCTION quaternion_mult AS Tquaternion: lhs AS Tquaternion, rhs AS Tquaternion
LOCAL q AS Tquaternion
q.w = lhs.w * rhs.w - lhs.x * rhs.x - lhs.y * rhs.y - lhs.z * rhs.z
q.x = lhs.w * rhs.x + lhs.x * rhs.w + lhs.y * rhs.z - lhs.z * rhs.y
q.y = lhs.w * rhs.y - lhs.x * rhs.z + lhs.y * rhs.w + lhs.z * rhs.x
q.z = lhs.w * rhs.z + lhs.x * rhs.y - lhs.y * rhs.x + lhs.z * rhs.w
RETURN q
ENDFUNCTION
FUNCTION camera_advance: cam AS Tcamera, d#
LOCAL xt#, yt#, zt#
xt = (cam.lx - cam.x) * d
yt = (cam.ly - cam.y) * d
zt = (cam.lz - cam.z) * d
cam.x = cam.x + xt
cam.y = cam.y + yt
cam.z = cam.z + zt
cam.ux =cam.ux + xt
cam.uy =cam.uy + yt
cam.uz =cam.uz + zt
cam.rx =cam.rx + xt
cam.ry =cam.ry + yt
cam.rz =cam.rz + zt
cam.lx =cam.lx + xt
cam.ly =cam.ly + yt
cam.lz =cam.lz + zt
ENDFUNCTION
FUNCTION camera_strafe: cam AS Tcamera, d#
LOCAL xt#, yt#, zt#
xt = (cam.rx - cam.x) * d
yt = (cam.ry - cam.y) * d
zt = (cam.rz - cam.z) * d
cam.x = cam.x + xt
cam.y = cam.y + yt
cam.z = cam.z + zt
cam.ux = cam.ux + xt
cam.uy = cam.uy + yt
cam.uz = cam.uz + zt
cam.rx = cam.rx + xt
cam.ry = cam.ry + yt
cam.rz = cam.rz + zt
cam.lx = cam.lx + xt
cam.ly = cam.ly + yt
cam.lz = cam.lz + zt
ENDFUNCTION
FUNCTION camera_rise: cam AS Tcamera, d#
LOCAL xt#, yt#, zt#
xt = (cam.ux - cam.x) * d
yt = (cam.uy - cam.y) * d
zt = (cam.uz - cam.z) * d
cam.x = cam.x + xt
cam.y = cam.y + yt
cam.z = cam.z + zt
cam.ux = cam.ux + xt
cam.uy = cam.uy + yt
cam.uz = cam.uz + zt
cam.rx = cam.rx + xt
cam.ry = cam.ry + yt
cam.rz = cam.rz + zt
cam.lx = cam.lx + xt
cam.ly = cam.ly + yt
cam.lz = cam.lz + zt
ENDFUNCTION
FUNCTION camera_roll: cam AS Tcamera, a#
LOCAL qUp AS Tquaternion
qUp.w = 0
qUp.x = cam.ux - cam.x
qUp.y = cam.uy - cam.y
qUp.z = cam.uz - cam.z
LOCAL qRight AS Tquaternion
qRight.w = 0
qRight.x = cam.rx - cam.x
qRight.y = cam.ry - cam.y
qRight.z = cam.rz - cam.z
LOCAL qRot AS Tquaternion
qRot.w = COS(a * rad/2)
qRot.x = (cam.lx - cam.x) * SIN(a * rad/2)
qRot.y = (cam.ly - cam.y) * SIN(a * rad/2)
qRot.z = (cam.lz - cam.z) * SIN(a * rad/2)
LOCAL W AS Tquaternion,W1 AS Tquaternion,W2 AS Tquaternion
W1 = quaternion_mult(qRot,qUp)
W2 = quaternion_conj(qRot)
W = quaternion_mult(W2,W1)
W = quaternion_normalize(W)
cam.ux = W.x + cam.x
cam.uy = W.y + cam.y
cam.uz = W.z + cam.z
// W = quaternion_mult(quaternion_mult(qRot,qRight), quaternion_conj(qRot)) <<< This does not work?!?!
W1 = quaternion_mult(qRot,qRight)
W2 = quaternion_conj(qRot)
W = quaternion_mult(W2,W1)
W = quaternion_normalize(W)
cam.rx = W.x + cam.x
cam.ry = W.y + cam.y
cam.rz = W.z + cam.z
ENDFUNCTION
FUNCTION camera_pitch: cam AS Tcamera, a#
LOCAL qUp AS Tquaternion
qUp.w = 0
qUp.x = cam.ux - cam.x
qUp.y = cam.uy - cam.y
qUp.z = cam.uz - cam.z
LOCAL qLook AS Tquaternion
qLook.w = 0
qLook.x = cam.lx - cam.x
qLook.y = cam.ly - cam.y
qLook.z = cam.lz - cam.z
LOCAL qRot AS Tquaternion
qRot.w = COS(a * rad/2)
qRot.x = (cam.rx - cam.x) * SIN(a * rad/2)
qRot.y = (cam.ry - cam.y) * SIN(a * rad/2)
qRot.z = (cam.rz - cam.z) * SIN(a * rad/2)
LOCAL W AS Tquaternion,W1 AS Tquaternion,W2 AS Tquaternion
W1 = quaternion_mult(qRot,qUp)
W2 = quaternion_conj(qRot)
W = quaternion_mult(W2,W1)
W = quaternion_normalize(W)
cam.ux = W.x + cam.x
cam.uy = W.y + cam.y
cam.uz = W.z + cam.z
W1 = quaternion_mult(qRot,qLook)
W2 = quaternion_conj(qRot)
W = quaternion_mult(W2,W1)
W = quaternion_normalize(W)
cam.lx = W.x + cam.x
cam.ly = W.y + cam.y
cam.lz = W.z + cam.z
ENDFUNCTION
FUNCTION camera_yaw: cam AS Tcamera, a#
LOCAL qRight AS Tquaternion
qRight.w = 0
qRight.x = cam.rx - cam.x
qRight.y = cam.ry - cam.y
qRight.z = cam.rz - cam.z
LOCAL qLook AS Tquaternion
qLook.w = 0
qLook.x = cam.lx - cam.x
qLook.y = cam.ly - cam.y
qLook.z = cam.lz - cam.z
LOCAL qRot AS Tquaternion
qRot.w = COS(a * rad/2)
qRot.x = (cam.ux - cam.x) * SIN(a * rad/2)
qRot.y = (cam.uy - cam.y) * SIN(a * rad/2)
qRot.z = (cam.uz - cam.z) * SIN(a * rad/2)
LOCAL W AS Tquaternion,W1 AS Tquaternion,W2 AS Tquaternion
W1 = quaternion_mult(qRot,qRight)
W2 = quaternion_conj(qRot)
W = quaternion_mult(W2,W1)
W = quaternion_normalize(W)
cam.rx = W.x + cam.x
cam.ry = W.y + cam.y
cam.rz = W.z + cam.z
W1 = quaternion_mult(qRot,qLook)
W2 = quaternion_conj(qRot)
W = quaternion_mult(W2,W1)
W = quaternion_normalize(W)
cam.lx = W.x + cam.x
cam.ly = W.y + cam.y
cam.lz = W.z + cam.z
ENDFUNCTION
FUNCTION X_6DOFCAMERA: cam AS Tcamera
X_MAKE3D cam.nearClip, cam.farClip, cam.FOV
X_CAMERAUP cam.x - cam.ux, cam.y - cam.uy, cam.z - cam.uz
X_CAMERA cam.x, cam.y, cam.z, cam.lx, cam.ly, cam.lz
ENDFUNCTION
FUNCTION debug_view: x, y, z, crad, rgb1, rgb2, rgb3
LOCAL rad, x1, y1, j, x2, y2
y1=SIN(0)*crad
x1=COS(0)*crad
FOR j=4 TO 360 STEP 4
y2=SIN(j)*crad
x2=COS(j)*crad
X_LINE x+x1,y+y1,z , x+x2,y+y2,z,0.1,rgb1
X_LINE x+x1,y+0,y1+z, x+x2,y+0,y2+z,1,rgb2
X_LINE x+0,y+x1,y1+z, x+0,y+x2,y2+z,1,rgb3
x1=x2
y1=y2
NEXT
X_DOT x,y,z,10,rgb1
X_DRAWAXES x+crad,y,z
X_DRAWAXES x-crad,y,z
X_DRAWAXES x,y+crad,z
X_DRAWAXES x,y-crad,z
X_DRAWAXES x,y,crad+z
X_DRAWAXES x,y,-crad+z
X_PRINT "RIGHT X+",x+crad,y,z,0
X_PRINT "LEFT X-",x-crad,y,z,0
X_PRINT "UP Y+",x,y+crad,z,0
X_PRINT "DOWN Y-",x,y-crad,z,0
X_PRINT "OUT Z+",x,y,crad+z,0
X_PRINT "IN Z-",x,y,-crad+z,0
X_SETTEXTURE -1, -1
ENDFUNCTION
#10
Bug Reports / Re: MOUSEAXIS(0) and 1 inside X_MAKE3D
2012-Jun-29
The ideal result in that instance would be the precompiler to enforce a showscreen directly after the mouse read (I appreciate that's likely almost impossible to implement with functions, conditional statements etc). Possibly having 2 versions of the command - an inline one for speed and a generic "will always work but it's slower" version would be doable.
At the end of the day though, to not be a bug then like all other commands, it should always work, or it should be caught as a syntactical problem at compile time.
At the end of the day though, to not be a bug then like all other commands, it should always work, or it should be caught as a syntactical problem at compile time.
#11
Bug Reports / Re: MOUSEAXIS(0) and 1 inside X_MAKE3D
2012-Jun-29
Sorry, I disagree. There is no logical reason for having a link between 2D work, 3D work and reading data from the mouse. I should be able to call MOUSEAXIS at any point in my code and have it return the correct result. If I call it and it returns wrong/no information then it's a bug in my book.
#12
Just to clarify :
This occurs when control has passed to the IDE (eg. you have hit a breakpoint). If you then hit SHIFT-F5 (or use the menus to stop debugging) the program runs (continues) instead of stopping. Additionally it does not return focus to the program window (another bug?)
If you then select the program window to give it focus, SHIFT-F5 will stop the program.
This occurs when control has passed to the IDE (eg. you have hit a breakpoint). If you then hit SHIFT-F5 (or use the menus to stop debugging) the program runs (continues) instead of stopping. Additionally it does not return focus to the program window (another bug?)
If you then select the program window to give it focus, SHIFT-F5 will stop the program.
#13
Yes, control swaps back from the IDE to the program window and my program continues to execute (the graphics continue to update until I quit the program). It happens with both the key sequence and choosing the stop option off the debug menu.
#14
If I'm running my program (GLBasic v10.283) and it runs to a breakpoint, if I hit Debugger->Stop, or shift-f5, the program starts running again instead of stopping the execution flow. From this point it also ignores any further breakpoints it hits.
#15
As this has been in the queue for a long time I thought I'd ask if anything has happened in regards to this? The non-scroll change on the debug window would really help when debugging.
Being able to display the IDE and the running program at the same time would be great too - currently once you tab away from the program you can't get it back until the next showscreen runs.
Being able to display the IDE and the running program at the same time would be great too - currently once you tab away from the program you can't get it back until the next showscreen runs.