yep thats my problem then, i was using blitsurface...

with GLXGears demo i get i constant 60fps.

ive looked in to ogl with sdl and decided its time i make the jump(be it ill still be doing mainly 2d stuff so its not that bad). It seems to be fairly straight forward.

If it deems to much to handle i will go back with ur suggestion as im sure it would work for my application. thanks.

Update: SDL 1.2 now has HW acceleration, however it's restricted - you may use SDL_BlitSurface() to draw only HW surfaces to screen, drawing SW surfaces to screen will not work. Also alpha-surfaces do not work (you still can use colorkey surfaces and set per-surface alpha).
Alien Blaster can now be compiled using both SDL 1.2 and SDL 1.3 (both modes are HW-accelerated).
However Jooleem crashes, I still don't know why

pelya wrote:

kurosu wrote:Oh, I see now you are linked to a game that could be considered an alternative to Wormux!
Is it the next portage you'll produce?

Eh, what game? You mean Jooleem? It's a simple casual game where you have to select marbles of same color. How is that connected to Wormux?

On your profile, when looking at what your website is, one can see OpenLieroX (which would be a huge burden to port). My post was entirely useless, I was just teasing you;sorry for the noise.

pelya wrote:Update: SDL 1.2 now has HW acceleration, however it's restricted - you may use SDL_BlitSurface() to draw only HW surfaces to screen, drawing SW surfaces to screen will not work. Also alpha-surfaces do not work (you still can use colorkey surfaces and set per-surface alpha).

This forces the alpha color format to be RGBA4444, right? One cannot use S/W RGBA32 surfaces and do its own work.

Anyway, I'd be curious to see what improvement it brings to alienblaster by not using h/w instead of s/w. (an idle wondering not worth detracting you from your work)

kurosu wrote:

pelya wrote:

kurosu wrote:Oh, I see now you are linked to a game that could be considered an alternative to Wormux!
Is it the next portage you'll produce?

Eh, what game? You mean Jooleem? It's a simple casual game where you have to select marbles of same color. How is that connected to Wormux?

On your profile, when looking at what your website is, one can see OpenLieroX (which would be a huge burden to port). My post was entirely useless, I was just teasing you;sorry for the noise.

I want to port it too, however that game relies on huge amount of libraries, and SDL surfaces usage is all messed up - it's rendering slowly even on PC, on Android it will give 1-2 FPS at best. Plus it requires 4 additional buttons, so it's useless to port it until we'll have on-screen keyboard.
I thought of porting some not so complicated game, like TeeWorlds for example.

pelya wrote:I want to port it too, however that game relies on huge amount of libraries, and SDL surfaces usage is all messed up - it's rendering slowly even on PC, on Android it will give 1-2 FPS at best.

From the look of it, I wouldn't embark on such a port.

On a side note, I've quickly browsed the code, seeing float used in many places. Wormux requires fixed point for some parts linked to networking to achieve proper reproducibility between platforms that floats don't allow.

pelya wrote:Plus it requires 4 additional buttons,

Wormux might be simpler, but I guess you now understand how touch-only devices are not a priority target.

pelya wrote:until we'll have on-screen keyboard.

How do you intend to do this? In the case of Wormux, there are a number of text entries that require keyboard. Ideally and naively, I would have imagined the native Java keyboard associated to a hidden Java text entry that would receive the input text. Not sure if associating one Java entry per native entry (requires allocation from native code, with risks of improper deallocation & the like) or a single Java entry for all natives entries, and exchange of the string.

While I am at annoying everyone with my musings, at some point I shall look into JNI for the http get we do with curl. This is a waste to have a full blown library to do this while the OS already provide

pelya wrote:I thought of porting some not so complicated game, like TeeWorlds for example.

Every other day, I seem to discover a Worms derivative with impressive advantages over Wormux. Hard to not feel depressed.

kurosu wrote:On a side note, I've quickly browsed the code, seeing float used in many places. Wormux requires fixed point for some parts linked to networking to achieve proper reproducibility between platforms that floats don't allow.

Network code allows for slight differences in item positions - I'm still rewriting it, I think I'll never finish and ppl will use old incompatible versions anyway .

kurosu wrote:

pelya wrote:Plus it requires 4 additional buttons,

Wormux might be simpler, but I guess you now understand how touch-only devices are not a priority target.

Yeah, they should've designed that Android phones with key layout of Sony PSP. I can't imagime myself buying such an expensive device just to do phone calls, it's definitely for gaming.

kurosu wrote:

pelya wrote:until we'll have on-screen keyboard.

How do you intend to do this? In the case of Wormux, there are a number of text entries that require keyboard. Ideally and naively, I would have imagined the native Java keyboard associated to a hidden Java text entry that would receive the input text. Not sure if associating one Java entry per native entry (requires allocation from native code, with risks of improper deallocation & the like) or a single Java entry for all natives entries, and exchange of the string.

That might work for text input (though I think we won't be able to make it half-transparent).
For plain game action you need different keyboard - on-screen arrow keys + huge Fire and Jump buttons, and some smaller, like Menu/Pause etc.

or maybe

well I can draw you tons of such layouts.

Most probably I'll just draw semi-transparent images of buttons over the already drawn game screen inside SDL_Flip(). I even imagine doing some simple alphabet using line-drawing routines only, if it will be semi-transparent we can fill whole phone screen with huge QWERTY buttons, not just small buttons in lower part of screen as it is done in other Android apps.

kurosu wrote:While I am at annoying everyone with my musings, at some point I shall look into JNI for the http get we do with curl. This is a waste to have a full blown library to do this while the OS already provide

Better don't - libcurl is an awesome library (and it's tiny too), and Java HTTP classes suck.

kurosu wrote:

pelya wrote:I thought of porting some not so complicated game, like TeeWorlds for example.

Every other day, I seem to discover a Worms derivative with impressive advantages over Wormux. Hard to not feel depressed.

It's not Worms clone, it's Liero clone (which is technically a Worms clone but realtime, kinda another genre).
On the other hand, porting OpenLiero (not OpenLieroX) to Android will be easy, however it still requires 3 buttons for game actions, and to dig into dirt you have to press Left&Right at the same time, which is impossible with joystick/trackball/whatever.

kurosu wrote:

pelya wrote:Update: SDL 1.2 now has HW acceleration, however it's restricted - you may use SDL_BlitSurface() to draw only HW surfaces to screen, drawing SW surfaces to screen will not work. Also alpha-surfaces do not work (you still can use colorkey surfaces and set per-surface alpha).

This forces the alpha color format to be RGBA4444, right? One cannot use S/W RGBA32 surfaces and do its own work.

Anyway, I'd be curious to see what improvement it brings to alienblaster by not using h/w instead of s/w. (an idle wondering not worth detracting you from your work)

I've added back SW mode - just use SDL_SetVideoMode() without SDL_HWSURFACE flag and it'll be the same renderer as before, with in-memory buffer where you can blit your 32-bit alpha surfaces.
RGBA4444 will give two times less memcpy() then RGBA32, so I'd better use it, even with SW surfaces (you may complain about color quality degradation however).

Edit: also I've published OpenTyrian game on market
Edit2: I'm going on 2-weeks vacation, and I intend to not even touch my PC there, so see you!

Just wanted to say i am using PsPad text editor with this, works almost as an ide.

You start a new project and then set compile options and it will comiple the program and capture the output as if it were meant for it. very slick.

Tried updating to the latest git version.

I'm getting "cannot find symbol" on everything that is located at android.view.MotionEvent (methods getPointer*)

Not knowing java/the android platform, I imagine this has to do with Froyo multitouch support, thus requiring the corresponding SDK, of limited use to me, in particular if I don't intend to use it in my application.

kurosu wrote:Tried updating to the latest git version.

I'm getting "cannot find symbol" on everything that is located at android.view.MotionEvent (methods getPointer*)

Not knowing java/the android platform, I imagine this has to do with Froyo multitouch support, thus requiring the corresponding SDK, of limited use to me, in particular if I don't intend to use it in my application.

Are you getting that error when compiling or when trying to run the application on device?
Maybe you're using Android 1.6 SDK to compile, you should use 2.0 or newer - I'm compiling it with 2.2 (Froyo) SDK. It will still run on 1.6 devices, with multitouch disabled (it worked on both ADP1 and Evo, and on 1.6 emulator when I've checked it last time).
The multitouch code is located in file src/Video.java, you can try to comment out "MultiTouchInput" class. Or use older GIT revision - I've added multitouch in the last few commits.

MultiTouch? awesome. Is there any progress on keeping the program from crashing when you press the home button? Or is there way we can make an SDL_Event for when the program gets minimized for any reason?(so we can save state or close program out correctly).

edit: im also not sure if the sdl_buttondown and buttonup events are being reported right(of course my code could be wrong, but i dont think so).

as i understood it when u press down on the screen it should fire sdl_buttondown and then when release ur press it fires the sdl_buttonup.

tho its far from doing this :\

pelya wrote:

kurosu wrote:Tried updating to the latest git version.

I'm getting "cannot find symbol" on everything that is located at android.view.MotionEvent (methods getPointer*)

Not knowing java/the android platform, I imagine this has to do with Froyo multitouch support, thus requiring the corresponding SDK, of limited use to me, in particular if I don't intend to use it in my application.

Are you getting that error when compiling or when trying to run the application on device?
Maybe you're using Android 1.6 SDK to compile, you should use 2.0 or newer - I'm compiling it with 2.2 (Froyo) SDK. It will still run on 1.6 devices, with multitouch disabled (it worked on both ADP1 and Evo, and on 1.6 emulator when I've checked it last time).

I would, if there wasn't so many risks to screw again the setup. I'm using ndk4b, and I don't really care for nicer SDKs as long as they don't improve the native part. And in my case, I don't intend to code specific multitouch support (my phone doesn't support it so it would be a nightmare to debug), so SDK>1.6 is a waste for me.

And is that different from indicating a minSDKversion or whatever in the xml files?

The multitouch code is located in file src/Video.java, you can try to comment out "MultiTouchInput" class. Or use older GIT revision - I've added multitouch in the last few commits.

I indeed did that, and forced DifferentTouch to return SingleTouch or whatever it is.

Here are more reports from my side:

• SDL generates what I think is unwanted events from the accelerometer, even if I have the phone laying still on a table. It quickly shots burst of kp9/kp7/up/down events
• Sorry if I sound insistent, but detecting the availability of at least a hardware dpad to deactivate the accelerometer feature would be useful, but currently, it seems broken from the look of the events it generates; this breaks any handling of the events, so I'll have to workaround this if you don't
• The display remains black (not sure if it even seats idle or what) if I use double-buffering or H/W surfaces; the emulator does the same, though
• I'm not hearing any audio; I know it's playing though, because the game slows down

Jug6ernaut wrote:MultiTouch? awesome. Is there any progress on keeping the program from crashing when you press the home button? Or is there way we can make an SDL_Event for when the program gets minimized for any reason?(so we can save state or close program out correctly).

Neither SDL 1.2 nor SDL 1.3 support multiple mouse/pointer devices, so to get multitouch events you should open joysticks 1-3 and read their axis values - axes 0 and 1 are coordinates, axis 2 is pressure force, axis 3 is touch spot radius (if your device won't return zeros for these values of course).
Joystick 0 reports accelerometer events, if you've enabled joystick support from ChangeAppSettings.sh. If it can open orientation sensor it will then use it instead of accelerometer, giving you 3-axis joystick instead of 2-axis for accelerometer. If the user selected "accelerometer as cursor keys" via startup config menu it won't report any events on joystick 0.

I did not check if that stuff works at all, I'll write simple test program when I'll come back from vacation (that will be in a week).

The crash when program is minimized will be fixed, not too soon though.

kurosu wrote:I would, if there wasn't so many risks to screw again the setup. I'm using ndk4b, and I don't really care for nicer SDKs as long as they don't improve the native part. And in my case, I don't intend to code specific multitouch support (my phone doesn't support it so it would be a nightmare to debug), so SDK>1.6 is a waste for me.

And is that different from indicating a minSDKversion or whatever in the xml files?

You can use older NDK with newer SDK, I don't see any problem with this. It's not different from minSDKversion.

kurosu wrote:Here are more reports from my side:

• SDL generates what I think is unwanted events from the accelerometer, even if I have the phone laying still on a table. It quickly shots burst of kp9/kp7/up/down events
• Sorry if I sound insistent, but detecting the availability of at least a hardware dpad to deactivate the accelerometer feature would be useful, but currently, it seems broken from the look of the events it generates; this breaks any handling of the events, so I'll have to workaround this if you don't
• The display remains black (not sure if it even seats idle or what) if I use double-buffering or H/W surfaces; the emulator does the same, though
• I'm not hearing any audio; I know it's playing though, because the game slows down

• Disable "Use accelerometer as joystick" and in ChangeAppSettings.sh don't select "Use accelerometer as cursor keys" in application startup config. KP7/KP9 events are reported if orientation sensor is used instead of accelerometer, I suppose there is a bug in my code - it should only open accelerometer if you're using it as cursor keys.
• I've tried your solution with checking sytstem configuration, and it fails on both my devices (ADP1 and hacked Evo), so I'm asking "What kind of controls do you have" when applications starts for the first time. If user selects dpad or trackball it will additionally ask if user wants to use accelerometer, and won't open accelerometer at all if not needed. Again, I think there's some bug in my code - please check if it opens accelerometer from OpenTyrian.
• You currently cannot draw SW surfaces onto video surface if you've opened video with HWSURFACE flag. It should write lot of warning messages in logcat if you're doing that.
• No idea about that - did audio work before my recent changes? Does it write "Opened audio blabla" to logcat?

kurosu wrote:And is that different from indicating a minSDKversion or whatever in the xml files?

You can use older NDK with newer SDK, I don't see any problem with this. It's not different from minSDKversion.

OK, in fact I wasn't more thinking "will 'setting it to some value' allow me to compile your code with older SDK" but this was wrong.

Disable "Use accelerometer as joystick" and in ChangeAppSettings.sh don't select "Use accelerometer as cursor keys" in application startup config. KP7/KP9 events are reported if orientation sensor is used instead of accelerometer, I suppose there is a bug in my code - it should only open accelerometer if you're using it as cursor keys.

Yeah sorry, I should have indeed reported the content of AppSettings.cfg which is indeed:
AppNeedsArrowKeys=y
AppUsesJoystick=y

It's also because I wasn't sure what you actually meant in that script. Wormux requires a mouse, and can use a joystick (but still be content with keys only).

As for "Redefine common keys", we have fortunately added a screen to do edit keybindings, which is much less error-prone.

I've tried your solution with checking sytstem configuration, and it fails on both my devices (ADP1 and hacked Evo), so I'm asking "What kind of controls do you have" when applications starts for the first time.

OK, sad, but there seems to be no other way...

If user selects dpad or trackball it will additionally ask if user wants to use accelerometer, and won't open accelerometer at all if not needed.

Indeed, I didn't understand it was an exclusive choice. So now, there's no such event sent.

You currently cannot draw SW surfaces onto video surface if you've opened video with HWSURFACE flag. It should write lot of warning messages in logcat if you're doing that.

It doesn't. It simply hangs. No idea where.

No idea about that - did audio work before my recent changes? Does it write "Opened audio blabla" to logcat?

It was me being clueless (keys reassigned etc), so I confirm it works.

btw, I tried OpenTyrian, it works flawlessly and is very fluid. Congrats.