| Bada port? |
| Author
|
Thread |
 |
|
SX1Freak
Joined: 31 Jul 2011
Posts: 4
|
Keep up the good work. Wow, very interesting.
|
Sun Jul 31, 2011 9:01 pm |
|
|
Simmabo
Joined: 31 Aug 2010
Posts: 13
|
I just wondered what will happen if it does not pass certification to get into the Appstore.
Could you release it anyway / "inofficially"?
There must be a way to get this thing on the phone even without an appstore 
|
|
Fri Aug 12, 2011 11:52 am |
|
|
chrisws
Joined: 15 Apr 2011
Posts: 25
|
The BADA code has been merged into the master repository, but any official release will need to be based on the 1.3 branch. I have tried more than a dozen games in the build based on master and they all seem to run fine. I tried creating a build based on 1.3 but so far the app locks up in the launcher.
|
|
Tue Aug 23, 2011 10:11 pm |
|
|
|
|
chrisws
Joined: 15 Apr 2011
Posts: 25
|
quote:
Originally posted by hexaae
I'm sure you'll be able to solve the problem with v1.3....
Amazing video proofs of the bada port working on Wave S8500!
http://www.badaitalia.com/2011/08/26/video-scummvm-in-esecuzione-sulla-piattaforma-bada/
Thanks hexaae,
I'm uploading some more video's this morning. Sorry about the background noise, my camera is a bit dodgy.
I'm not really sure what the actual problem is with the 1.3 build, but what I have found is that in DefaultEventManager, the _artificialEventSource and _eventQueue members are somehow partially getting constructed with the same memory locations. In notifyEvent() the line _eventQueue.push causes a modification to _artificialEventSource.
This is probably one of the hardest types of problems to solve in C/C++ where a memory corruption is only noticed as a flow on effect and the root cause is somewhere else.
I thought maybe 1.3 used some different compiler options, but the config.mk files end up being more or less the same.
|
|
Fri Aug 26, 2011 10:04 pm |
|
|
|
|
LordHoto
ScummVM Developer
Joined: 30 Oct 2005
Posts: 863
Location: Germany |
quote:
Originally posted by chrisws
I'm not really sure what the actual problem is with the 1.3 build, but what I have found is that in DefaultEventManager, the _artificialEventSource and _eventQueue members are somehow partially getting constructed with the same memory locations. In notifyEvent() the line _eventQueue.push causes a modification to _artificialEventSource.
To which point in time do you compare the state of the objects? Right before the push in the same function?
|
|
Sat Aug 27, 2011 3:01 am |
|
|
chrisws
Joined: 15 Apr 2011
Posts: 25
|
quote:
Originally posted by LordHoto
quote:
Originally posted by chrisws
I'm not really sure what the actual problem is with the 1.3 build, but what I have found is that in DefaultEventManager, the _artificialEventSource and _eventQueue members are somehow partially getting constructed with the same memory locations. In notifyEvent() the line _eventQueue.push causes a modification to _artificialEventSource.
To which point in time do you compare the state of the objects? Right before the push in the same function?
Yes, right before. Then after the push an infinite loop occurs in the event dispatcher. I get a different result by swapping the position of the variable declarations, so something must be overwriting the class instance somewhere.
I'm currently trying to work out whether the problem occurs in the simulator build. The debugging tools are pretty flakey and crash often. Also sometimes you could be busy studying the debugger output, and then the handset reboots. It might be that using the new 2.0 SDK helps lead to the source of the problem.
Do you know if there were any commits to master around June/July that in any way could have fixed this? I don't know why I don't get the problem in master.
Cheers,
Chris
|
|
Sun Aug 28, 2011 9:28 am |
|
|
chrisws
Joined: 15 Apr 2011
Posts: 25
|
quote:
Originally posted by chrisws
quote:
Originally posted by LordHoto
quote:
Originally posted by chrisws
I'm not really sure what the actual problem is with the 1.3 build, but what I have found is that in DefaultEventManager, the _artificialEventSource and _eventQueue members are somehow partially getting constructed with the same memory locations. In notifyEvent() the line _eventQueue.push causes a modification to _artificialEventSource.
To which point in time do you compare the state of the objects? Right before the push in the same function?
Yes, right before. Then after the push an infinite loop occurs in the event dispatcher. I get a different result by swapping the position of the variable declarations, so something must be overwriting the class instance somewhere.
I'm currently trying to work out whether the problem occurs in the simulator build. The debugging tools are pretty flakey and crash often. Also sometimes you could be busy studying the debugger output, and then the handset reboots. It might be that using the new 2.0 SDK helps lead to the source of the problem.
Do you know if there were any commits to master around June/July that in any way could have fixed this? I don't know why I don't get the problem in master.
Cheers,
Chris
It's all fixed. I moved the inline virtual functions in default-events.h to default-events.cpp and the problems went away. It was most likely a compiler bug.
|
|
Sat Sep 03, 2011 4:43 am |
|
|
hexaae
Joined: 25 Jun 2010
Posts: 35
|
That's great!
It's 99,9% complete then?
Bada 2.0 is coming BTW... just a matter of a few weeks!
|
|
Sun Sep 04, 2011 6:21 pm |
|
|
Marius_Linux
Joined: 12 Sep 2011
Posts: 2
Location: Germany |
Hey chrisws!
It's great that your'e almost don with doing the port.
But can you explain how to import the sourcecode into bada SDK and how to compile it, so we can test it before it's released because the leaked app has got sound problems and crashes if you try to save the games.
THX in advance
Marius_Linux
|
|
Mon Sep 12, 2011 7:11 pm |
|
|
chrisws
Joined: 15 Apr 2011
Posts: 25
|
quote:
Originally posted by Marius_Linux
Hey chrisws!
It's great that your'e almost don with doing the port.
But can you explain how to import the sourcecode into bada SDK and how to compile it, so we can test it before it's released because the leaked app has got sound problems and crashes if you try to save the games.
THX in advance
Marius_Linux
I've noticed a few forums opening up where people have reported various results. I wonder whether the sound problems are related to using BADA 2.0?
If you want to build the code, be prepared to spend about 1/2 day or so:
1. Click https://github.com/chrisws/scummvm/tree/branch-1-3-1-a then click "Downloads"
2. Unzip the package to a clean folder, then follow the instructions in backends/platform/bada/README.TXT
3. You will also need some additional DOT files here:
https://github.com/chrisws/scummvm/tree/master/dists/bada
Also, email me privately for the updated manifest.xml file.
I'm currently testing the waters with Samsung about getting this released.
I wouldn’t trust the leaked version. The setup steps involve using a dummy certificate which could allow the app to do anything. There is no guarantee the code hasn’t been changed and no one is claiming to be the builder.
|
|
Tue Sep 13, 2011 3:32 am |
|
|
Dokugogagoji
Joined: 01 Sep 2010
Posts: 6
|
quote:
Originally posted by chrisws
I wouldn’t trust the leaked version. The setup steps involve using a dummy certificate which could allow the app to do anything. There is no guarantee the code hasn’t been changed and no one is claiming to be the builder.
I was the builder but I haven't personally distribuited them and I am asking to remove those earlier builds from BadaItalia forum who started to do this with my nick. I have removed the link from the forum. I had a private Skydrive folder who have shared them with my friend... I have no doubt who distributed them. But he is not a developer, so no code change and the build was only binary.
There were four builds where they were linked with the external libreries.
the first one missed the event manager, so it was unusable.
the second one leaked for every external libraries..so crashes for missing zlib imports and the flag USES_ZLIB makes it using comperssed saved game...and all FLAC/OGG/MAD support were missing.
the third one corrected the zlib issue.
the fourth one has libflac, libogg, libmad, libvorbis and game wip engines, fixes for Bada 2 (the volume slider is only visibile when running bada 1.0 and 1.2 ), removed control mouse only, long press for click, double press for right click.
md5 were the same from the multiupload leaked one so he has some arcane power to keep the md5 the same or probably it is not changed.
The modified code is all on form.cpp
http://pastebin.com/v1jknUwh
and form.h
http://pastebin.com/NujgAqCG
certificate is the developer one, who it is used by Bada SDK. However, manifest.xml is not overrided by the certificate.
There is the SYSTEM_SERVICE privilege who
essential if your app is hungry for some system and runtime specific info like the memory or battery levels
http://www.badadev.com/44-privilege-groups-in-bada/
With this privilege can't do anything else, so it can't use social and privacy sensitive api.
..however I have stopped to do them in the shared folder since I was wrong on trusting my friend...
|
|
Tue Sep 13, 2011 3:12 pm |
|
|
Marius_Linux
Joined: 12 Sep 2011
Posts: 2
Location: Germany |
Compiling ScummVM
hey chrisws thx for your reply!
But I've got some problems:
1st Problem:
quote:
The following were added to ~/utils for zlib:
ar:
#!/bin/sh
${ARM_BIN}/arm-samsung-nucleuseabi-ar.exe $*
gcc:
#!/bin/sh
${ARM_BIN}/arm-samsung-nucleuseabi-gcc.exe $*
I can't find the folder an dfiles. Can you tell me how to find them?
2nd Problem: When i try to run configure for the libraries(except zlib) I get the error "C Compiler cannot create excutables"
Can you tell me what I am doing wrong??
|
|
Tue Sep 13, 2011 6:46 pm |
|
|
Dokugogagoji
Joined: 01 Sep 2010
Posts: 6
|
...if people want to try and cwarrensmith want to check the frontend...
http://www.multiupload.com/UAAY6SMOX6
Just remember:
-->binary copy of external libraries included for easy compiling... so for not trusting people, the weird doubt will remain..and I have no right/will to remove that.
-->The manifest is designed for Bada 2 with the only SYSTEM_SERVICE. Bada 2.0 manifest works on Bada 1.2 as is.
-->The project is designed for the bada 2.0.0 sdk. So model (right click on the project-->proprieters-->bada build-->model) should be changed in according to the current.
-->Who use Bada 2 SDK, watch out to the WaveWVGA model bug. Binary needs to have adjusted the imports via an hex editor (search for
/FOsp.so
/FGrahpicsEgl.so
/FGraphicsOpenGl.so
inside the executable on .Target-* folder in the project folder after the build. Replace them with the only file name and zeroes in the rest of the path). You could compile with the WaveHVGA and the binary should be already fixed. Not tested the latter however.
Known compiling issues:
-->claiming for the variable-sized enums on 32-bit libraries even forcing it..but it seems to be not a problem.
|
|
Tue Sep 13, 2011 7:44 pm |
|
|
|
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
Powered by phpBB © 2001, 2006 phpBB Group
Forum design by ScummVM team, icons by raina
|
|
