Jump to content

Working port to Ios


Guest SyntaxError

Recommended Posts

ie and gemrb don't support arbitrary resolutions, much less changing it ingame. The changing could be implemented, but you'd still need to pregenerate all the gui datafiles for the required resolutions beforehand using the widescreen mod.

Link to comment

So, there are more such masks...

Well, i'll try to find all. This change doesn't seem to affect SDL 1.2 on linux.

 

The 0's are the correct value to use there.

I was told that 1.2 simply ignores the invalid values while 1.3 reports an error and refuses to create the sprite.

 

On the other hand, i found only one place where i had to change them to 0.

 

I fixed the walksound crash too.

Link to comment
ie and gemrb don't support arbitrary resolutions, much less changing it ingame. The changing could be implemented, but you'd still need to pregenerate all the gui datafiles for the required resolutions beforehand using the widescreen mod.

 

I'm not necessarily looking for an arbitrary resolution. I'd be happy running 800x600 in landscape, but setting it to 800x600 for some reason gives me that result that is vertically squished visually, but yet the touch coordinates are all (seemingly) the correct non-squished position. Maybe this is a bug in SDL.

 

the ipad screen is 768x1024 so running at 800x600 in portrait chops off 32 pixels and wraps them to the other side. If I could just run in landscape mode even if its only at 800x600 that would solve that problem. Ideally id like to scale the 800x600 rendering to fill the entire 1024x768 area I would think this could be done through SDL.

 

I'm also not looking to be able to dynamically switch orientation, although for what its worth, adding the SDL_RESIZABLE flag to SDL_SetVideoMode does allow me to dynamically swap the orientation. there is nothing setup to catch the SDL resize event to recall setvideomode so the frame you swap on is rotated (and vertically squished) but no following frames are drawn. Since i dont care about dynamically swapping orientation im not going to bother with that.

Link to comment

normally for iphone/ipad you can start in whatever orientation the device is in or you can fore your own.

 

with SDL it doesnt matter if you start is portrait or landscape SDL (at least thats what im blaming) will always draw in portrait. Even forcing the app to be in landscape using UIInterfaceOrientation doesn't work. UIInterfaceOrientation will force the simulator to rotate as it should but everything is rendered "sideways".

 

Editing the SDL source to force the window to any landscape size has the opposite effect and SDL will always draw landscape regardless of UIInterfaceOrientation or any thing else. this is how i was able to get it to draw landscape. The perplexing thing is that the touchscreen coordinates are correct and not vertically challenged like the rendering. This leads me to believe that it isnt SDL that is doing the squishing tho im obviously not sure. I may have to play some in the sdlvideo.cpp code to see if i cant see if it is happening there. Ill play with the SDL calls in there and see if i cant figure this out.

Link to comment

:p;)

 

Success! I even went a step farther and disabled the status bar. maybe i ought to make that optional tho.

 

gemrbipadlandscape.png

 

Now i dee to figure out how to do this without hacking SDL... Im sure there is some sdl api or somesuch i should be using.

 

I did not have to make any gemrb code changes.

Link to comment
So, there are more such masks...

Well, i'll try to find all. This change doesn't seem to affect SDL 1.2 on linux.

 

The 0's are the correct value to use there.

I was told that 1.2 simply ignores the invalid values while 1.3 reports an error and refuses to create the sprite.

 

On the other hand, i found only one place where i had to change them to 0.

 

I fixed the walksound crash too.

 

 

Missed this post this morning...

 

Yes avenger there are 2 others (I think only 2):

 

SDLVideoDriver::CreateSprite:

void* p = SDL_CreateRGBSurfaceFrom( pixels, w, h, bpp, w*( bpp / 8 ),

0, 0, 0, 0 );

 

SDLVideoDriver::CreateSprite8:

void* p = SDL_CreateRGBSurfaceFrom( pixels, w, h, 8, w, 0, 0, 0, 0 );

 

I had already fixed the footstep crash by using strncpy instead, but good to see you actually fixed it instead of working around it. I should have realized that it was an off by 1 error in retrospect, but hindsight is always 20/20.

Link to comment
if it is really a sdl bug, go nag the sdl/sdl porting people, so they can fix it upstream. Remember, 1.3 didn't even have a proper release yet.

 

Its not a bug I dont think. the problem was my first hack was resizing only the SDL view. to fix i simply set the UIWindow size then set the SDL view size to that so that the window and view are the same size. I should just be able to grab a pointer to the UIWindow from inside gemrb and set its frame which should fix this without hacking SDL.

 

The issue now is that I need to call objective c code from inside c++ code. the same thing applies to the keyboard input; i know exactly where i need to ask for the virtual keyboard i just need to setup some c functions to to bridge gemrbs c++ with apples objective-c.

Link to comment

I would like to help on this, since I'm an iOS developer, too.

 

Do you have it uploaded to a repo? If not, would you be willing to upload it or send it as a ZIP?

Link to comment

Keyboard now works... sortta. delete doesn't work for some reason. Turns out that SDL provides this for me so all I had to do was create a header file with the proper symbols and include it into textedit.cpp and add some preprocessor wrapped function calls in TextEdit::Draw ;)

 

gemrbipadkeyboard.png

 

@Andy

 

At this point there isn't much iOS specific things left to do. I'm working on getting this merged with the gemrb source tree before it is available. many of my changes have been committed there in better ways + additional improvements and fixes. As soon as the project is merged ill post here and anybody can have at it.

 

If you dont want to wait for that to help there is 1 thing that MUST be done for this to be useful. Python needs to be compiled as a static library; I will obviously be stripping out the python code when merging with gemrb so even after its merged you wont be able to build gemrb without first being able to build python.

 

@anybody that cares

 

as an aside: I'm not in fact an iOS developer (i dont even own an ios device); this is my first experience. I'm actually not even a c/c++ developer, hadn't touched it since school. I do have hobby experience developing on OS X (obj-c), and professionally i develop PHP.

 

Turns out that GemRB is just well done and porting it is a breeze. very portable code; I'm very impressed with the work behind it. :p

 

Let this be a lesson to anybody out there that wants to help, but doesn't think they know how. Whats the harm in trying? worst case scenario you learn something, best case you contribute something valuable like a port to a previously unsupported platform.

 

My hat goes off to the real heros of GemRB :laugh:

Link to comment
Guest Fabian

Epic work mate. Do you think that Baldur's Gate 2 will be completely playable on an iPad? What about Planescape Torment? I would very much like to help out with this but unfortunately I don't have a Mac.

Link to comment
Yes avenger there are 2 others (I think only 2):

 

SDLVideoDriver::CreateSprite:

void* p = SDL_CreateRGBSurfaceFrom( pixels, w, h, bpp, w*( bpp / 8 ),

0, 0, 0, 0 );

 

SDLVideoDriver::CreateSprite8:

void* p = SDL_CreateRGBSurfaceFrom( pixels, w, h, 8, w, 0, 0, 0, 0 );

The first one is not easy to fix, the masks should be 0 only when bpp==8. But the second one was already fixed (i don't know when, because i didn't do it).

I think (or rather, hope) no one calls CreateSprite with bpp=8 and masks. (You need to call CreateSprite8 instead)

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...