GemRB 0.8.0 released! (Fork Me edition)

[Xelasarg]

Everything running nicely so far. I'm really missing the mouse pointer, though. Especially at higher resolutions (1280x720) it's pretty difficult to pick up items from the floor.

 

Two- and three-finger gestures work quite well, with two small exceptions: whenever I do a two finger-press to highlight items, GemRB also shows HP info above the characters' heads (probably meant to be like this, though, I guess); and almost always, when I lift the fingers up from the display again after a two- or three-finger gesture, GemRB picks up one of the two / three locations I tapped as a move command and the whole party runs off there.

 

I still have to figure out how to get custom font working again, but that should be another path issue on my side. I'll have a closer look at my cfg and font.2da files later.

 

Cheers!

[SyntaxError]

probably meant to be like this, though, I guess

yup

 

I'm really missing the mouse pointer, though

it will be back at some point, but it is a poor way to deal with ground piles. In short, we need to do something better instead of relying on cursors. Pinch-to-zoom will be added at somepoint, but we need a proper opengl capable renderer first. Chiv had some other ideas that might alleviate the issue too, but he seems to have vanished again.

 

GemRB picks up one of the two / three locations I tapped as a move command and the whole party runs off there

probably a regression caused by the last touch fix; most certainly isnt supposed to do that and didn't used to. will look into it next week, thanks for reporting it.

 

I still have to figure out how to get custom font working again, but that should be another path issue on my side. I'll have a closer look at my cfg and font.2da files later.

yeah nothing changed here other than now we support multibyte fonts. set CustomFontPath in your cfg file and then edit the fonts.2da for whatever game as per the instructions on the wiki

[SyntaxError]

GemRB picks up one of the two / three locations I tapped as a move command and the whole party runs off there

probably a regression caused by the last touch fix; most certainly isnt supposed to do that and didn't used to. will look into it next week, thanks for reporting it.

 

I am unable to reproduce this... keep in mind i only have the iOS simulator for testing, so its quite possible that it can only be reproduced with actual hardware.

[Xelasarg]

It doesn't happen everytime, I can avoid this behaviour by releasing all fingers at the exact same time. But that can be quite tricky sometimes and hardly ever works with three finger gesture. I've also noticed that GemRB sometimes draws a selection box after a two finger scroll.

I've got a Galaxy Note 2 (N7100), but I'm sure it happens with other phones, too.

Thanks for your efforts!

[SyntaxError]

It doesn't happen everytime, I can avoid this behaviour by releasing all fingers at the exact same time. But that can be quite tricky sometimes and hardly ever works with three finger gesture. I've also noticed that GemRB sometimes draws a selection box after a two finger scroll.

I've got a Galaxy Note 2 (N7100), but I'm sure it happens with other phones, too.

Thanks for your efforts!

 

the selection box bug is known and can be avoided by making sure the game area is "focused" (tap it with a single finger before attempting to scroll it). its so minor i havent bothered to do anything about it.

 

sounds like the other bug indeed cant be reproduced for the reason i gave. I'll have to coordinate a fix with somebody that has a touchscreen device.

[SyntaxError]

new android build should fix the following:

• corruption caused by playing videos
  
• selection rect being created when scrolling the viewport if viewport was not already focused
  
• performing party action after performing a multitouch gesture
  

please report any touch input bugs here.

[Trasd]

I tried to resist, but I can't help it - if possible, I want to help with this project, even given my current time restraints. If nothing else, I can at least continue beta testing. Until I bought BG1 and BG2 specifically for GemRB, I had never played any of these games before, so I coming at this project with a fresh perspective and with plenty of RPG experience.

 

To this end, I've been reading about Git and doing some other research, though as expected, I'm progressing slowly - reading a little here and there when I get time.

 

I'm not trying to hijack this thread either, but right now my interest are primarily in helping with the Android port, so this thread should be as good a place to ask some questions as any, if no one minds. If anyone wants me to create a new thread for this, I will, but I'm expecting these to be my only questions for now. These answers will help me determine how deeply I want to get involved. If I do progress to the point where I have specific technical questions, I will definitely seek answers using the normal channels.

 

Here are my questions:

• I'm still wrapping my head around Git, is this statement right (I'm using psch as an example, I hope you don't mind); all the work psch has done so far will be available for anyone to review as long as we keep the project clone up to date, is this correct (sorry, I'm only near the beginning of the tutorial)?
  
• The problem I'm having where I can't run 16bpp is a result of SDL 2.0 (this is where the software rendering code is currently located), is this true?
  
• Is there a central location where project goals are kept? What I mean is that I keep seeing phrases like "Eventually we will get...," and "we will be..." I would hate to spend a lot of time pursuing a particular path only to find out later that it is the complete opposite goal of what the team was shooting for.
  
• I do see that a few others have their own repository within the GemRB SF page, is this because they are making changes not in line with the project team's goals?
  
• All my compilers are Borland (now Embarcadero). I know Assembly and C\C++ (I'm learning a few others like Java, but it's really close to C anyway), are all the tools needed to build GemRB open source or at least have a free alternative?
  
• When SyntaxError said, "speaking of the new renderer, its worth mentioning that it will upscale the game using hardware acceleration, so you can set resolution to something like 640x480 to achieve better performance without it being too small to play (obviously it will be quite fugly at such a low res, but you get the idea)." This is a future goal because all of the rendering right now is software, right? Or, does it work now, but via the software renderer?
  
• Are the multi-finger gestures documented somewhere, I couldn't find anything on them?
  

Thanks in advance for anyone willing to answer these few questions!

[SyntaxError]

I'm still wrapping my head around Git, is this statement right (I'm using psch as an example, I hope you don't mind); all the work psch has done so far will be available for anyone to review as long as we keep the project clone up to date, is this correct (sorry, I'm only near the beginning of the tutorial)?

yes, all of psch's work is in our source tree

 

 

The problem I'm having where I can't run 16bpp is a result of SDL 2.0 (this is where the software rendering code is currently located), is this true?

true, but the 16bpp vs 32bpp rendering is not the real speed issue. a good hardware accelerated rendering pipeline in GemRB should run fine for any newish Android.

 

Is there a central location where project goals are kept? What I mean is that I keep seeing phrases like "Eventually we will get...," and "we will be..." I would hate to spend a lot of time pursuing a particular path only to find out later that it is the complete opposite goal of what the team was shooting for.

 

wiki should have all that, but you would want to coordinate your work on the IRC channel.

 

I do see that a few others have their own repository within the GemRB SF page, is this because they are making changes not in line with the project team's goals?

 

without knowing specifically what you are referring to I would say that is because each developer has their own repo to work on then final work is merged into the main repo.

 

All my compilers are Borland (now Embarcadero). I know Assembly and C\C++ (I'm learning a few others like Java, but it's really close to C anyway), are all the tools needed to build GemRB open source or at least have a free alternative?

for android yes. depending on what portion of GemRB you want to work on you would need C++, or python, or Java (android only). Java would be needed to implement a GUI config interface for example.

 

When SyntaxError said, "speaking of the new renderer, its worth mentioning that it will upscale the game using hardware acceleration, so you can set resolution to something like 640x480 to achieve better performance without it being too small to play (obviously it will be quite fugly at such a low res, but you get the idea)." This is a future goal because all of the rendering right now is software, right? Or, does it work now, but via the software renderer?

 

Ok, the graphics are all rendered via software rendering, but our SDL2 renderer can then take that output and scale it using hardware to fit the screen. so you can render a smaller size and scale it to get better performance while still using the entire screen. make sense?

 

Are the multi-finger gestures documented somewhere, I couldn't find anything on them?

 

on the wiki

[lynx]

Re other repos: before we were on github it was harder to share larger work-in-progress or throwaway code (pastebins just don't cut it), so some developers used personal forks on github. I'll remove that list now that we moved, since it's all available through the main interface.

 

Re goals: apart from the overarching "make the originals playable, more modder friendly and device agnostic", there is little coordination. We hack on what we want, so gemrb also ends up with various addons and extensions that may be of little use to most users (like the Twisted interface to our python console) and some that turn out to be hits (like ctrl-w).

 

We did have some talks about roadmaps, but nothing really came out of it (except that 1.0 should have all the games completable). Unless people really lack their own itches to scratch, setting arbitrary goals can sometimes be even detrimental to productivity. That's also why my planned bug/feature list for the next release is always changing. Some things get done, while some postponed due to being temporary too boring, too invasive (nearing the next release) or getting superceeded by something more fun. While I am the release manager, the list is mostly for me, with sometimes some wishlist items included that I then bug other people about. Apart from Brad, I don't think anyone else has tangible personal todos.

 

What needs to be done projectwise is written in the todo on the wiki: http://www.gemrb.org/wiki/doku.php?id=todo

It includes targets of all levels, difficulties and required prior game knowledge. You can't miss by fixing something on that incomplete list (you can see there're not many input or sdl details there). Guidance is always available.

[Trasd]

Re other repos: before we were on github it was harder to share larger work-in-progress or throwaway code (pastebins just don't cut it), so some developers used personal forks on github. I'll remove that list now that we moved, since it's all available through the main interface.

 

Re goals: apart from the overarching "make the originals playable, more modder friendly and device agnostic", there is little coordination. We hack on what we want, so gemrb also ends up with various addons and extensions that may be of little use to most users (like the Twisted interface to our python console) and some that turn out to be hits (like ctrl-w).

 

We did have some talks about roadmaps, but nothing really came out of it (except that 1.0 should have all the games completable). Unless people really lack their own itches to scratch, setting arbitrary goals can sometimes be even detrimental to productivity. That's also why my planned bug/feature list for the next release is always changing. Some things get done, while some postponed due to being temporary too boring, too invasive (nearing the next release) or getting superceeded by something more fun. While I am the release manager, the list is mostly for me, with sometimes some wishlist items included that I then bug other people about. Apart from Brad, I don't think anyone else has tangible personal todos.

 

What needs to be done projectwise is written in the todo on the wiki: http://www.gemrb.org...oku.php?id=todo

It includes targets of all levels, difficulties and required prior game knowledge. You can't miss by fixing something on that incomplete list (you can see there're not many input or sdl details there). Guidance is always available.

 

Thank you - that makes sense.

 

 

 

The problem I'm having where I can't run 16bpp is a result of SDL 2.0 (this is where the software rendering code is currently located), is this true?

true, but the 16bpp vs 32bpp rendering is not the real speed issue. a good hardware accelerated rendering pipeline in GemRB should run fine for any newish Android.

 

And there in lies the problem! LOL, I am far from a "newish" tablet, in fact I'm using a flashed B&N Color reader (overclocked and tweaked). That's why I am so desperate to work on my other Android projects - my wife says this hobby must be self-sustaining. LOL, again!

 

 

 

Is there a central location where project goals are kept? What I mean is that I keep seeing phrases like "Eventually we will get...," and "we will be..." I would hate to spend a lot of time pursuing a particular path only to find out later that it is the complete opposite goal of what the team was shooting for.

 

wiki should have all that, but you would want to coordinate your work on the IRC channel.

 

Ah - I don't know how I missed that - thanks.

 

 

 

When SyntaxError said, "speaking of the new renderer, its worth mentioning that it will upscale the game using hardware acceleration, so you can set resolution to something like 640x480 to achieve better performance without it being too small to play (obviously it will be quite fugly at such a low res, but you get the idea)." This is a future goal because all of the rendering right now is software, right? Or, does it work now, but via the software renderer?

 

Ok, the graphics are all rendered via software rendering, but our SDL2 renderer can then take that output and scale it using hardware to fit the screen. so you can render a smaller size and scale it to get better performance while still using the entire screen. make sense?

 

Yes, that's exactly what I wanted to hear! So, I will try 0.8.0 at a lower resolution keeping the aspect ration correct.

 

 

 

Are the multi-finger gestures documented somewhere, I couldn't find anything on them?

 

on the wiki

 

I don't know how I missed this either - thanks again. I guess the next step is to look at the code, fix my resolution, and have fun...

[Trasd]

The dream sequence in GemRB-0.8.0-git-1b488a-touch7.apk doesn't make the screen go all wonky anymore, but it is still not functioning right on my system!

 

After I rest, the dream sequence displays correctly, but it doesn't go away. If I tap done, I get the regular play screen back, but if I select any other control (map, save, etc), instead of showing the correct screen, it goes back to the dream sequence! After this, the normal play screen does not display right again.

 

This behavior is consistent.

 

EDITED

My native screen resolution is 600 x 1024 and I cannot find a good resolution to play BG1 at. This is the minimum widescreen will work with and there is nothing close to this aspect ratio native to BG1. Any suggestions? My system will not handle 0.8.0 at 1024 x 600 (FPS is too low) and I can't get a lower one to work. Any help is appreciated - I'm probably over thinking this as usual, but the solution escapes me at present.

[SyntaxError]

After I rest, the dream sequence displays correctly, but it doesn't go away. If I tap done, I get the regular play screen back, but if I select any other control (map, save, etc), instead of showing the correct screen, it goes back to the dream sequence! After this, the normal play screen does not display right again.

 

doesnt at all sound like anything android specific.

 

As for resolution, you would want a ratio native to your screen, not native to BG1. there has to be an option lower than 1024x600 doesnt there (820x480?)? the native res for BG1 is less than that after all (640x480). there is no reason you cant use 640x480, you will just have black bars on the side of your screen.

[Trasd]

After I rest, the dream sequence displays correctly, but it doesn't go away. If I tap done, I get the regular play screen back, but if I select any other control (map, save, etc), instead of showing the correct screen, it goes back to the dream sequence! After this, the normal play screen does not display right again.

 

doesnt at all sound like anything android specific.

 

As for resolution, you would want a ratio native to your screen, not native to BG1. there has to be an option lower than 1024x600 doesnt there (820x480?)? the native res for BG1 is less than that after all (640x480). there is no reason you cant use 640x480, you will just have black bars on the side of your screen.

 

640 x 480 isn't displaying correctly. This may be because widescreen was run on the PC before I copied it over. I will have to try it without widescreen to see if it will work that way. The 640 seems to work fine (with the black bars, of course), but the height is screwy. With the older versions, I did try to play at this resolution when I first got the game, but there is simply not enough real estate, which is why I used widescreen in the first place. If I had to play at that resolution, I wouldn't, I'd go back to 0.7.x (which I have done again so I can get some play-time in). Basically, 640 x 480 is unacceptable for me, everything is just too big and blocky, and I can't see far enough around me.

 

When I get tired of the bugs in 0.7.2, or I have to reload 0.8.0 to get past a problem point and get a saved game (like I did this time), I will try 820 x 480 without widescreen (if possible). I did try that resolution with 0.8.0, but I got just a blank screen.

 

Thanks though. I may concentrate on building the game with psch's fixes, but using the old SDL. This wouldn't be anything I would expect everyone to run, but to be a temporary solution for people like me with older or non-standard systems having trouble with 0.8.0 and SDL 2. I do really want to run 0.8.0 though, the controls are really great. GemRB is definitely heading in the right direction. I can't wait for it to run on my system. Like I said, I have only BG 1 & 2, so I won't be running out of games any time soon.

[SyntaxError]

I may concentrate on building the game with psch's fixes, but using the old SDL

touch input (gestures) requires SDL 2, as does the software keyboard (unless im mistaken that pelya build was lacking this). Any custom config interface/alerts psch creates too.

 

I imagine any problems you have with WS are due to you having previously applied a different res to the data. also maybe you are forgetting to change your config res to match the data res.

[lynx]

the video thing does sound generic, but it still works fine here, so it must be limited to sdl2 users.