Bada port?

SX1Freak · Post by **SX1Freak** » Sun Jul 31, 2011 9:01 pm

Keep up the good work. Wow, very interesting.

Simmabo · Post by **Simmabo** » Fri Aug 12, 2011 11:52 am

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

chrisws · Post by **chrisws** » Tue Aug 23, 2011 10:11 pm

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.

hexaae · Post by **hexaae** » Fri Aug 26, 2011 6:21 pm

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/vi ... orma-bada/

chrisws · Post by **chrisws** » Fri Aug 26, 2011 10:04 pm

hexaae wrote: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/vi ... orma-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.

hexaae · Post by **hexaae** » Fri Aug 26, 2011 10:08 pm

chrisws wrote:
hexaae wrote: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/vi ... orma-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.

Need to ask to original scummVM coders then... maybe they can help.

LordHoto · Post by **LordHoto** » Sat Aug 27, 2011 3:01 am

chrisws wrote: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?

chrisws · Post by **chrisws** » Sun Aug 28, 2011 9:28 am

LordHoto wrote:
chrisws wrote: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

chrisws · Post by **chrisws** » Sat Sep 03, 2011 4:43 am

chrisws wrote:
LordHoto wrote:
chrisws wrote: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.

hexaae · Post by **hexaae** » Sun Sep 04, 2011 6:21 pm

That's great!

It's 99,9% complete then?

Bada 2.0 is coming BTW... just a matter of a few weeks!

Marius_Linux · Post by **Marius_Linux** » Mon Sep 12, 2011 7:11 pm

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

chrisws · Post by **chrisws** » Tue Sep 13, 2011 3:32 am

Marius_Linux wrote: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 ... 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.

Dokugogagoji · Post by **Dokugogagoji** » Tue Sep 13, 2011 3:12 pm

chrisws wrote: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...

Marius_Linux · Post by **Marius_Linux** » Tue Sep 13, 2011 6:46 pm

hey chrisws thx for your reply!
But I've got some problems:
1st Problem:

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??

Dokugogagoji · Post by **Dokugogagoji** » Tue Sep 13, 2011 7:44 pm

...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.

Bada port?

Compiling ScummVM