Messages

I work odd days, so never know when my next day off is,
if I'm awake and not at work, I'll be online to chat.

As I understand it, it connects as a bluetooth keyboard,
so in theory yes it should work, as the iPhone will pick up the keyboard presses,
and GLBasic should be able to read them.

The problem is the mode 7 effect is done with hardware and tiles,
where as the drawing system on GLBasic is not.
This is how the SNES could do it on the fly, you would create a background image built up of tiles, 128x128 tiles,
and the mode 7 would skew it,
by changing the tiles, you would get your animation, as it redrew the background image and skewed it each frame.

Unfortunately to do the equivalent in GLBasic is quite processor intensive.
Redrawing 128x128 (16384) tiles each frame is a helluva lot.
You're better of doing as erico suggests, work out what part of the map is in view,
and only redraw that, almost like a flat raycaster.

http://en.wikipedia.org/wiki/Mode_7

It's kind of how a capacitive digitiser works,
as it's reading fingers, which aren't as precise as a resistive touch stylus,
it works out from what information it gets of the blob that is a finger to chose a point.
And according to ampos' code, it's acting as it should.

As far as I can tell there is no problem with your device or GLBasic,
it's just how it is with a capacitive touch screen.

Okay, one more attempt
You say the iPhone is not picking up any detection in the top part of the screen,
where the status bar for signal coverage and battery are shown.
This code example splits the screen into 30 strips of 16 pixels and detects when you are touching inside one of the strips.
If there is a problem with your touch screen then you will not be able touch the first strip.
Let us know how it responds.

Code (glbasic) Select Expand


GLOBAL TouchX[], TouchY[], TouchB1[]
DIM TouchX[5]
DIM TouchY[5]
DIM TouchB1[5]

GLOBAL Zone[]
DIM Zone[30]
GLOBAL i, dummy

SETSCREEN 320,480,TRUE
SYSTEMPOINTER TRUE
LIMITFPS 30

WHILE TRUE
FOR i=0 TO 4
SETACTIVEMOUSE i
MOUSESTATE TouchX[i],TouchY[i],TouchB1[i],dummy
IF TouchB1[i]
Zone[ASR(TouchY[i],4)]=1
ENDIF
NEXT
FOR i=0 TO 29
DRAWLINE 0,i*16,320,i*16,RGB(255,255,255)
IF Zone[i]=1
DRAWRECT 0,i*16,320,16,RGB(255,255,255)
ENDIF
Zone[i]=0
NEXT
SHOWSCREEN
WEND


I do not think that example is useful because the problem is that the zero of the digitizer screen does not match the zero of the graphical display . Your example will draw the square where it thinks you has touched but this is not meant to work properly.

Then check my previous post where I wrote code to print up the x,y co-ordinates of each touch and the button/touch status.
http://www.glbasic.com/forum/index.php?topic=6326.msg50522#msg50522

Nice idea! Think of some improvements:

-combo bonus points (3x Knee, 3xFoot, Foot-Knee-Foot-Knee-Foot ...)
-Add flying birds to the scene that you can kick with the ball.
-Insects that crawl on the floor that you can stomp on? (evil?)
-Different balls (football, tennis ball, golf ball(footbag?), rugby egg)

The combo and bird suggestions remind me of the footbag event in California games.
Looks like this could become a great game with some tweaking and additions.

Here's some code to visually test the touch screen

Code (glbasic) Select Expand


SETSCREEN 320,480,TRUE
SYSTEMPOINTER TRUE
LIMITFPS 30

GLOBAL TouchX[],TouchY[],TouchZ[],TouchB1[]
DIM TouchX[5]
DIM TouchY[5]
DIM TouchZ[5]
DIM TouchB1[5]

GLOBAL i,dummy

WHILE TRUE
FOR i=0 TO 4
SETACTIVEMOUSE i
MOUSESTATE TouchX[i],TouchY[i],TouchB1[i],dummy
IF TouchB1[i]=1
DRAWRECT TouchX[i]-32,TouchY[i]-32,64,64,RGB(255,255,255)
ENDIF
NEXT
SHOWSCREEN
WEND


By digitizer he's referring to the touch layer of the screen that converts your touches to co-ordinates.

Everything I've coded for the iPhone detects the whole screen from 0,0 to 320,480.
Sounds like there must be a bug somewhere in the code.
Or possibly a faulty device. The iPhone screen sometimes will lose sensitivity on certain horizontal bands of the touchscreen,.
Easiest thing would be to write some code to test the state of your touches,

Code (glbasic) Select Expand


GLOBAL TouchX[], TouchY[], TouchB1[]
DIM TouchX[5]; DIM TouchY[5]; DIM TouchB1[5]

GLOBAL i, dummy

SETSCREEN 320,480,TRUE
SYSTEMPOINTER TRUE
LIMITFPS 30

WHILE TRUE
FOR i=0 TO 4
SETACTIVEMOUSE i
MOUSESTATE TouchX[i],TouchY[i],TouchB1[i],dummy
PRINT "x:"+TouchX[i]+" y:"+TouchY[i]+" b:"+TouchB1[i],16,i*32
NEXT
SHOWSCREEN
WEND


Looks good.

If you're looking to add more features you could add power-ups in the air, such us slowing down / speeding up, gravity, time bonus +/-, points, multi-ball, ball/shoe size, etc, or obstacles in the air to offer different game play.

My vote for multiball.

384 is to do with spaces - do you have any in the project name or path?  Are you using the latest hotfix?

I downloaded and installed the latest fix,
and as you can see by the output text, there are no spaces in the project name

Code (glbasic) Select Expand

Android=C:\Dropbox\GLBasic\8BitBob\android
I wonder if it's because it starts with a number?

Just copied the code into a new project
EightBitBob and it works fine, so it looks like starting your project name with a number will cause a 384 error.

Q:\Compiler\platform\android\android-sdk-windows\tools\ant\main_rules.xml:384: Compile failed; see the compiler error output for details.

Sounds like the android icon isn't present.

I'm not sure how that would be the case,
as my older program compiled fine, and in both instances I've not created an icon yet,
they both use the standard GLBasic icon.
I even created a new project and copy pasted the source code over and got the same error.
I wonder if it's a command or something, but unfortunately I have no idea what error 384 refers to,
and no idea how to "see the compiler error output for details"

Also I found the program that did compile to be running very sluggishly,
even though it's only setup to run at 30fps using a few sprites.
This was tested on a new Samsung Galaxy S II.

Also tested on a HTC wildfire,
found that the it ran incredibly slowly on that.
Wonder if it's anything to do with it being in debug mode?
An interested  thing, it scaled on both devices, 480x800 and 320x240 automatically.

I managed to get an older project to compile and create an APK file for me to run on an android device.
But when I try to compile 8BitB.Ob it comes up with the following error.

Code (glbasic) Select Expand

_______________________________________
*** Configuration: ANDROID ***
precompiling:
GPC - GLBasic Precompiler V.7.917 SN:6525c6b7 - 3D, NET
Wordcount:1349 commands
compile+link:
BUILDSRIPT

BUILD FAILED
Q:\Compiler\platform\android\android-sdk-windows\tools\ant\main_rules.xml:384: Compile failed; see the compiler error output for details.

Total time: 2 seconds
Android=C:\Dropbox\GLBasic\8BitBob\android
success
_______________________________________
*** Finished ***
Elapsed: 12.8 sec. Time: 22:25
Build: 1 succeeded.

Also I found the program that did compile to be running very sluggishly,
even though it's only setup to run at 30fps using a few sprites.
This was tested on a new Samsung Galaxy S II.

Imagine a top down game with an illuminated field of vision around the player, this is effectively what FPS shooters do in effect as you can only see a specific region based on your view. This way enemies will appear fairly quickly and help create tension as you don't wanna rush too quickly around a play area. Also the usage of panned sound and volume levels would help create orientation as to where enemies are to be pre warned but still provide enough tension knowing they can appear without warning at any time

Something like this?
http://www.appspy.com/i-found-you-review