Supertux 2 (0_3_3) -- General Dev Questions


Mr Rob

Active Member
Joined
Apr 23, 2011
Messages
805
Age
37
Location
Fargo, North Dakota, USA.
Hello all:


First off, I am a Linux guy, but it tends to be more geared toward servers, and less games/graphics, so that's my general background.


I currently have a functioning copy of "Super Tux 2" (0_3_3 downloaded from their SVN) running on my Pandora. I built on the Pandora itself, and when cmake barked about missing libraries, I just opkg installed them recklessly, uninstalling things if it had a conflict with an already installed file.


I can get it full screen, and changed the resolution in the source to support the Pandora. Bad news is that for the moment, I can only get the SDL renderer to work correctly, and not yet OpenGL (I haven't done the OpenGL ES conversion, I'd need to read a lot about OpenGL yet and was hoping to make it work without learning graphics, ha.).


SDL is slow. Slow as in 16 frames per second, and jerky, jumping between 8 and 30.


Questions:


1 Would it be foolish for me to even try to get SDL working faster? Does it have the capabilities or am I better off going down the OpenGL ES route?


2. I remember reading that there were custom made versions of some graphics libraries on everyone's Pandora, is it possible that I overwrote those by using the package manager? Would that result in my current SDL renerer version of Super Tux to be slow?


3. Is anyone else currently working on SuperTux2?


And general tips would be helpful, I don't think I have any other questions at the time.


I really just want to play SuperTux2 on my Pandora, cause it's awesome.
 
Your not going to speed up SDL software render. Converting it to GLES will be the only way to attempt any improvement.

Understood. SDL is CPU bound then?


OpenGL ES might not be too bad.

Yes the software path is all CPU and theres not much that can improve it. OpenGL is usually not too bad to convert over depends what they used.
 
I also remember seeing a bash script (either around here or on some other forums) that would at least identify lines that would probably need GLES conversion. It was one line with find and grep, but I can't seem to find it.


Does it ring any bells?
 
Question:


Why are you trying to run the "unstable" version? The version of SuperTux you're trying to play is not very well tested and incredibly... well... unstable. It's a preview of features that are supposed to be in Milestone 2. If you're looking for gameplay, it would be a lot better to use Milestone 1 (v0.1.3).


Another question:


How are you even using plain SDL? I recall that Milestone 1.9 has dropped plain SDL support and now only allows OpenGL rendering. Also, SDL software rendering isn't that slow, especially not on C++. Pygame for Python is in fact a binding of SDL and it's being used for Pandora-compatible games, apparently; Pygame not only doesn't discourage software rendering, it encourages it. In fact, hardware-accelerated rendering can in some cases be slower than software rendering. I wouldn't be surprised if when you ran SuperTux 0.1.3, it would run at full speed in plain software rendering mode. We used to have an incredibly slow computer here (definitely slower than the Pandora), and it ran SuperTux milestone 1 with no issues. OpenGL mode didn't even work properly, so it was always set to use plain SDL rendering.
 
Question:


Why are you trying to run the "unstable" version? The version of SuperTux you're trying to play is not very well tested and incredibly... well... unstable. It's a preview of features that are supposed to be in Milestone 2. If you're looking for gameplay, it would be a lot better to use Milestone 1 (v0.1.3).

Well, I've played through the 'Supertux2' version I've seen in some Linux Distro Repo (Ubuntu maybe? I forget) and it had more features, levelsets, and yet seemed stable enough for enjoyable play.


I've also played Supertux (v0.1.3) that EvilDragon ported already for the Pandora, and about a third of the way through you get glitchy backgrounds that stops it from being playable. I may just try to fix that, but I wanted to see if Supertux2 would work.

Another question:


How are you even using plain SDL?

Pretty sure I'm using SDL, but not 100%. For the 0.3.3 source I checked out, there's an gl and sdl source directories, and after fiddling a bit, hard coded resolution and full screen variables in the sdl directory, and gave me the changes I wanted. I recognize that this isn't the most convincing proof in the world. Plus there are still --renderer command line arguments to support both. So their 0.3.3 version appears to have both. (And again, noob when it comes to graphics.) The more I look the less I'm sure; I should learn graphics one day.


I should check to see what it uses when I run it in Debian.

I recall that Milestone 1.9 has dropped plain SDL support and now only allows OpenGL rendering. Also, SDL software rendering isn't that slow, especially not on C++. Pygame for Python is in fact a binding of SDL and it's being used for Pandora-compatible games, apparently; Pygame not only doesn't discourage software rendering, it encourages it. In fact, hardware-accelerated rendering can in some cases be slower than software rendering. I wouldn't be surprised if when you ran SuperTux 0.1.3, it would run at full speed in plain software rendering mode. We used to have an incredibly slow computer here (definitely slower than the Pandora), and it ran SuperTux milestone 1 with no issues. OpenGL mode didn't even work properly, so it was always set to use plain SDL rendering.
 
onpon4 is clever. Debian 6 with Supertux 0.3.3 built from source runs perfect with SDL, and runs and even just looks bad with opengl set as the renderer.


Overclocking to 900 or so results in my build running pretty well, getting a good and consistent frame rate.


When I turn off sound, it becomes flawless. Supertux 0.3.3 uses OpenAL for sound that I had to build from source, are there better ways to do it?
 
I also remember seeing a bash script (either around here or on some other forums) that would at least identify lines that would probably need GLES conversion. It was one line with find and grep, but I can't seem to find it.


Does it ring any bells?

maybe this ?



Code:
#!/bin/sh


search() {

find . -name "*.h" -o -name "*.c" -o -name "*.cpp" -exec grep -Hn "$*" {} \;

}


listIssues() {

search SDL_WM_GrabInput

search SDL_WarpMouse

search SDL_GL

search GL_CLAMP

search glColor|grep -v glColor4f

search glPushAttrib

search glPolygonMode

search GL_QUADS |grep glDrawArrays

search SDL_Init

search SDL_OPENGL

search SDL_ShowCursor

search glClearDepth

search SDL_Quit

search gluBuild2DMipmaps

search glTexImage2D

search glBegin

}


listIssues|sort -u


look here for the tutorial http://pandorawiki.org/Porting_to_GLES_from_GL
 
I've also played Supertux (v0.1.3) that EvilDragon ported already for the Pandora, and about a third of the way through you get glitchy backgrounds that stops it from being playable. I may just try to fix that, but I wanted to see if Supertux2 would work.

Well, that's odd. I've never experienced anything like that playing SuperTux on a PC. What do you mean by "glitchy backgrounds", exactly?
 
I've also played Supertux (v0.1.3) that EvilDragon ported already for the Pandora, and about a third of the way through you get glitchy backgrounds that stops it from being playable. I may just try to fix that, but I wanted to see if Supertux2 would work.

Well, that's odd. I've never experienced anything like that playing SuperTux on a PC. What do you mean by "glitchy backgrounds", exactly?

Glitchy backgrounds: It only occurs on the port for the Pandora from EvilD, it doesn't happen on my Linux laptop. It's as if the resolution isn't correctly changed, the right third of the screen will preserve whatever the background was before the screen loaded, and all the baddies leave blurs on the screen.


Verbally, that's a terrible description, I'll take a picture at the end of the day.
 
Sounds like the res was set to 800x480 but the game should run at 640x480.


Maybe someone should try to stretch the backgroundimages to 800x480 and try if it helps.
 
Sounds like the res was set to 800x480 but the game should run at 640x480.


Maybe someone should try to stretch the backgroundimages to 800x480 and try if it helps.

I think I've got it. We're talking Supertux 0.1.3 if anyone's listening.


When ported, the backgrounds were stretched to 800x480. Some levels don't have a background image defined, however, and instead use a gradient, probably drawn on the fly. Make a background for them, define it in the level, and we'll be laughing.


I'll tinker and see what I can do.


I am still interested in 0.3.3 running and ready to go. It's playable; some levels are slower due to some transparent aspects. But still worth playing, I think at least.
 
Maybe this should be split into a Supertux 0.1.3 thread....


I now have a PND file with a fixed background for the problem I mentioned earlier. I recognize that Pickle and Evildragon were the original porters (as stated on both dl.openhandhelds and apps.openpandora.org; it's not in repo.* at all) and don't want to step on their toes.


Can I simply upload it to the repo(s) myself, or would proper protocol be to provide EvilD and Pickle a patch, for which then they apply it and upload?
 
Sounds like the res was set to 800x480 but the game should run at 640x480.


Maybe someone should try to stretch the backgroundimages to 800x480 and try if it helps.

I think I've got it. We're talking Supertux 0.1.3 if anyone's listening.


When ported, the backgrounds were stretched to 800x480. Some levels don't have a background image defined, however, and instead use a gradient, probably drawn on the fly. Make a background for them, define it in the level, and we'll be laughing.


I'll tinker and see what I can do.


I am still interested in 0.3.3 running and ready to go. It's playable; some levels are slower due to some transparent aspects. But still worth playing, I think at least.

I see, so the gradients threw the port off. Probably because the original SuperTux made an assumption about the needed size for the gradients. That's funny, because in one of Craig's old videos, he briefly played SuperTux on his prototype Pandora, and the game was properly pillarboxed. So what's being done with the extra 160x480 pixels? Does it show you more of the level? Not such a good idea for a game like SuperTux that has levels designed with the assumption that the view size is going to be the same (heck, I think even basic gameplay relies on this assumption; for example, it keeps Tux on the first third of the 640 width screen).


Actually, I wonder something: by any chance, do enemies seem to pause a bit in 0.1.3 at 800x480, or do they start walking as soon as you see them? The former would make the game look odd, but the latter seems like it would mess up the level design quite a bit (enemies falling off cliffs, etc).
 
Last edited by a moderator:
Yeah, better render to 640x480 and uns notaz sdl to scale to fullscreen if needed.


Doesn't preserve aspect, but meh...
 
I see, so the gradients threw the port off. Probably because the original SuperTux made an assumption about the needed size for the gradients. That's funny, because in one of Craig's old videos, he briefly played SuperTux on his prototype Pandora, and the game was properly pillarboxed. So what's being done with the extra 160x480 pixels? Does it show you more of the level? Not such a good idea for a game like SuperTux that has levels designed with the assumption that the view size is going to be the same (heck, I think even basic gameplay relies on this assumption; for example, it keeps Tux on the first third of the 640 width screen).


Actually, I wonder something: by any chance, do enemies seem to pause a bit in 0.1.3 at 800x480, or do they start walking as soon as you see them? The former would make the game look odd, but the latter seems like it would mess up the level design quite a bit (enemies falling off cliffs, etc).

Yes, most levels have a background image that was 640x480 and when originally ported changed to 800x480. A couple levels don't have a background image defined, thus probably has SDL draw a background. On the Pandora, when hacked to 800x480, on the couple levels that don't have a background defined, you just end up with pixels on the right that get overwritten by the world screen, and then objects on the screen; you end up with a blurry mess (attached, taken from my poor webcam).


Simply making a background image and editing the level file to use it makes it all better.

Yeah, better render to 640x480 and uns notaz sdl to scale to fullscreen if needed.


Doesn't preserve aspect, but meh...

As for game elements, I understand both your points, but I've never actually noticed things (enemies, mostly) being triggered at the wrong time due to the slightly bigger screen. Probably implies that the triggers occur far off screen, for either 640x480 or 800x480 (or this was changed when ported, also; I came to the party much later). And I've played a lot of Supertux.

2011-09-12-163452.jpg
 
Last edited by a moderator:
What about super tux2 infact what's the difference?


Sent from my Windows Phone 7 device using Board Express
 
Back
Top