OpenXcom Forum
Contributions => Builds & Ports => Topic started by: Shin-NiL on July 13, 2010, 04:18:04 pm
-
Hello everybody, considering the requests from users from Dingoonity (https://www.dingoonity.org/) community, I just created a makefile to compile openxcom to Dingoo-linux. It was only necessary to make some minor code changes, which follows in the patch file (REV. 96).
And here's the Makefile.dingoo
PROG = openxcom.dge
SRCS = $(wildcard *.cpp)
OBJS = $(SRCS:.cpp=.o)
CXX = mipsel-linux-g++
SDL-CONFIG = /opt/mipsel-linux-uclibc/usr/bin/sdl-config
CXXFLAGS = -Wall -O2 `$(SDL-CONFIG) --cflags` -DDINGOO
LDFLAGS = `$(SDL-CONFIG) --libs` -lSDL_gfx -lSDL_mixer
$(PROG): $(OBJS)
$(CXX) $(OBJS) $(LDFLAGS) -o $(PROG)
clean:
rm -f $(PROG) *.o
.PHONY: clean
As I can see the application is running just fine on my device.
I hope this help ;)
-
Instead of replacing CXX and adding SDL-CONFIG in makefile, you can run make like this:
PATH=$PATH:/opt/mipsel-linux-uclibc/usr/bin/
CXX=mipsel-linux-g++
export CXX PATH
make
I also think
if (SDL_Init(SDL_INIT_EVERYTHING) < 0)
should be replaced in code with
if (SDL_Init(SDL_INIT_VIDEO | SDL_INIT_AUDIO | SDL_INIT_JOYSTICK | SDL_INIT_TIMER) < 0)
for all platforms so only neccessary things are initialized.
Instead of pathing initialization of `scale` variable you can just run game as
openxcom -scale 1
-
Thank you for your help, Eeyoocah5Moh :)
I have only one question:
Instead of replacing CXX and adding SDL-CONFIG in makefile, you can run make like this:
PATH=$PATH:/opt/mipsel-linux-uclibc/usr/bin/
CXX=mipsel-linux-g++
export CXX PATH
make
This does not conflict with the sdl-config of my system, located in /usr/bin/?
Both directories /usr/bin/ and /opt/mipsel-linux-uclibc/usr/bin/ are already set in my path, permanently.
See ya!
-
Thanks for the makefile Shin-NiL, I've added it to the SVN. :)
I also took Eeyoocah5Moh's advice and just changed the initialization on all platforms, since OpenXcom only really uses VIDEO and AUDIO, and to keep the source clean of platform-specific-stuff.
-
Hello, could you make some photos (or even better - videos) of dingoo with openxcom? It could be interesting media to share on main site - what do you think SupSuper? OpenXCom on mobile consoles :D
-
Hello michal!
No prob, I'll upload a video as soon as possible ;)
-
Hello, could you make some photos (or even better - videos) of dingoo with openxcom? It could be interesting media to share on main site - what do you think SupSuper? OpenXCom on mobile consoles :D
Sounds good, I'll be sure to post it on the front page.
Mobile consoles are always neat, I should look into getting it working on my phone too. :P
-
And here's the vid:
https://www.youtube.com/watch?v=jScH-HEABwY
See ya!
-
Very nice!
Seems to run kinda slow though, should I be worried or is that normal for the hardware?
Also, what do you do for a keyboard? :P
-
I believe the feeling of slowness is because the virtual mouse movement speed. The only thing I really noticed were some flaws in music in some screens.
Anyway, our hardware is quite limited:
# CPU Ingenic JZ4732 @ 336MHz, underclocked from 360MHz (clocks up to 433MHz) (MIPS architecture)
# RAM 32MB @ 112MHz (in our case, shared for linux and applications)
# Input D-Pad, 2 shoulder, 4 face, Start & Select buttons, Mic.
Which keys are actually used in the game? I had never before played X-Com :-[
So far, I just missed the keyboard to type the base's name, but this can be corrected with a routine to use D-pad to switch characters.
Goodbye!
-
I believe the feeling of slowness is because the virtual mouse movement speed. The only thing I really noticed were some flaws in music in some screens.
Anyway, our hardware is quite limited:
# CPU Ingenic JZ4732 @ 336MHz, underclocked from 360MHz (clocks up to 433MHz) (MIPS architecture)
# RAM 32MB @ 112MHz (in our case, shared for linux and applications)
# Input D-Pad, 2 shoulder, 4 face, Start & Select buttons, Mic.
Which keys are actually used in the game? I had never before played X-Com :-[
So far, I just missed the keyboard to type the base's name, but this can be corrected with a routine to use D-pad to switch characters.
Goodbye!
Just the mouse actually, the keyboard is only used for typing in names so it looks like you did fine.
-
Hello guys,
here is my quick workaround which permits the base name's input on Dingoo platform.
I know it's not the best solution, but I think I'll use it for now.
See ya.
-
I also took Eeyoocah5Moh's advice and just changed the initialization on all platforms, since OpenXcom only really uses VIDEO and AUDIO, and to keep the source clean of platform-specific-stuff.
So you didn't add #ifdef DINGOO anywhere. Then -DDINGOO in makefile is unnecessary.
-
Yes, I did. Only in my latest patch "DingooTextEdit.patch".
But if you do not want to mess up your code, I can keep my changes separate.
EDIT: I don't know why, but the map was really, really slow on my Dingoo just after enter the base's name in Rev. 102 :(
EDIT2: In fact, everything slows down when the timer starts to run.
See ya!
-
Yes, I did. Only in my latest patch "DingooTextEdit.patch".
But if you do not want to mess up your code, I can keep my changes separate.
Well I meant I want to keep things consistent across all platforms (so if I have to optimize somewhere, I optimize everywhere, etc.), but I guess for limitations like these it's inevitable. I'll have a look.
EDIT: I don't know why, but the map was really, really slow on my Dingoo just after enter the base's name in Rev. 102 :(
EDIT2: In fact, everything slows down when the timer starts to run.
See ya!
Which revision did you have before? Does this only happen when you're looking at the globe?
We recently introduced textures and lighting to the globe, which require a lot more intensive drawing there, so that could be the problem. Depending on which causes the slowdown, it might be optimizable or at least have a "low-detail" version.
-
I had tested the revision 96 before. And yes, it only occurs while I'm looking at the globe and the timer starts to run.
See ya!
-
I have performed some optimizations on the globe, let me know if it has improved the performance on the Dingo.
If it still runs slow, you can try slowing down the geoscape timer by increasing the value in GeoscapeState.cpp line 102:
_gameTimer = new Timer(100);That is how often (in miliseconds) the ingame time moves and causes a globe redraw.
-
Sorry for going off-topic... I'll just start a new thread ;)
So by default the globe view is only updated 10 times per second? That seem kinda low compared to my refresh rate of 60 Hz...
Makes me wonder how the guys at Mythos ever got UFO to run smoothly on my 486, when OpenXcom on a much more powerful modern system crawls to a halt.
Is compiled C++ that inefficient? Is the code immature? Should we all quit our day jobs and go back to hacking assembler code?
Reason I'm asking is not to be an ass, but that my system ought to be able to generate a gazillion fps of this relatively simple low poly representation of Earth .. but somehow it doesn't :P
-
I have performed some optimizations on the globe, let me know if it has improved the performance on the Dingo.
If it still runs slow, you can try slowing down the geoscape timer by increasing the value in GeoscapeState.cpp line 102:
_gameTimer = new Timer(100);That is how often (in miliseconds) the ingame time moves and causes a globe redraw.
Thank you very much :)
I needed to extend the interval to 500 milliseconds. Continued slow but at least playable.
I think the Dingoo is not too good making too many floating point calculations.
-
Well I cached all the floating point calculations so they only need to be performed once everytime the globe is moved now. The slowness is probably from all the extra detail that was added in the latest revisions.
I'll just throw some options to turn down the globe detail later on, can't forget the little man. ;)
-
I've merged both makefiles so to build for Dingoo you should just need to set TARGET = DINGOO in the makefile, let me know if it still works.
-
I've merged both makefiles so to build for Dingoo you should just need to set TARGET = DINGOO in the makefile, let me know if it still works.
Sorry for the delay of two months :-[
Yes, it still compiling just fine, thank you. I just compiled the yaml-cpp lib for Dingux and I activated swap memory, once the new build does not run anymore without more RAM...
One thing I noticed was that the parameter "-scale 1" is no longer working, do you confirm that?
Thank you very much!
-
Yes, it still compiling just fine, thank you. I just compiled the yaml-cpp lib for Dingux and I activated swap memory, once the new build does not run anymore without more RAM...
I'm not sure what you mean. yaml-cpp takes up too much RAM or the game by now takes up too much RAM or...?
One thing I noticed was that the parameter "-scale 1" is no longer working, do you confirm that?
Yes, now you just specify the target resolution, eg. "-width 320 -height 200".
-
I'm not sure what you mean. yaml-cpp takes up too much RAM or the game by now takes up too much RAM or...?
Sorry for the bad structure of my sentence.
Actually, I do not know if the increased memory consumption is related to the use of the new library, since that is the first time that I use. What is certain is that only with the standard Dingoo Memory (32MB), the current version freezes on the loading screen.
Thanks again, SupSuper :)
-
Hello again Supsuper, how are you?
Last week I compiled the latest version of openxcom for Dingoo, the first I downloaded from github.
Congratulations for the great job, we can notice that the code had many optimizations, the map screen is much faster now :)
However, to compile the Dingoo version, I had to disable support for wstring, since Dingux does not support it. For this, I made a lazy and quick hack, just replacing wstring, wstringstream and so forth for its char compatible versions. The code compiles, but I had a side effect, all text is totally messed up at the display...
Do you have any suggestions to solve this problem?
Thanks again and keep good work.
-
Hello again Supsuper, how are you?
Last week I compiled the latest version of openxcom for Dingoo, the first I downloaded from github.
Congratulations for the great job, we can notice that the code had many optimizations, the map screen is much faster now :)
However, to compile the Dingoo version, I had to disable support for wstring, since Dingux does not support it. For this, I made a lazy and quick hack, just replacing wstring, wstringstream and so forth for its char compatible versions. The code compiles, but I had a side effect, all text is totally messed up at the display...
Do you have any suggestions to solve this problem?
Thanks again and keep good work.
Edit "bin\Language\Font.dat" in a text editor and remove all the non-ASCII characters that don't fit in std::strings (anything after ~). There will probably be other bugs from such a "quick hack", but at least it should be minimally readable in English.
-
Thanks ;)
Here is the results:
https://www.youtube.com/watch?v=DnzQcfZrPd4
-
Hello SupSuper, long time no see you!
I'm trying to compile OpenXcom for GCW-Zero (https://www.gcw-zero.com/), which is somekind of a enhanced Dingoo. However, I'm having trouble with OpenGL, you could tell me if this library is now mandatory? I've searched the wiki and found nothing saying that.
Thank you.
-
OpenGL is only for resizing screen (because is faster) and filters, you can easy cut out all opengl (#ifdef is probably best solution there).
-
If your device doesn't support OpenGL, you can just define __NO_SHADERS to disable OpenGL code.
-
If your device doesn't support OpenGL, you can just define __NO_SHADERS to disable OpenGL code.
Unfortunately it did not work. I will follow the Yankes suggestion and track down all OpenGL calls and then surrounding them with #ifdefs.
-
Okay, it worked :)
I still have some problems because the SDL_image provided on my toolchain does not supports lbm files...
Overall performance is very good, just shows slowness in battle map.
Thank you guys.
-
Good to know. :) If you want me to post any updated info or links in the Downloads page for your port, let me know.
-
Thank you!
I don't know if my build is good enough for a release, maybe a video ;)
I'll keep testing.
-
Hi Shin-NiL!
How is it going with the OpenXCom port for GCW-Zero?
I was thinking about taking a look at it, and maybe see if we can get it to a releaseable state. You might want to share your work so we don't need to do the same work. If you don't want to make it public jet, pm me.
I need to state though, I'm not a programmer (though I may be able to learn some, if I have time) so probably we'll need some external help in some parts. From the top of my head, for a release to GCW-zero we'll need:
1) Disable all display filters and resolution changes (this device has only a 320x240 display, so they are useless - well, in the future it will also have HDMI support, so in a later release, maybe they could be re-enabled... the newest firmware already does have openGL capabilities).
2) We need some kind of virtual keyboard for A) Save game naming (or, we could workaround this by auto-naming; the saves already have the in-game time stamped on them, so naming is no obligatory. Maybe we could have at least GEOSCAPE or BATTLESCAPE as an autoname?) and B) Base naming and C) (optional) soldier naming. Most of the game works without a keyboard, but some parts do use it.
3) The current d-pad emulation of the mouse on the GCW-zero is borderline-unusable (at least it is not comfortable). We need to A) wait for GCW-Zero devs to tell us if there is a analog-nub mouse emulation planned (I'd presume it is, it's just more work than the D-pad one, which is why it is not done yet) or B) Make the cursor moveable by an analog joystick in OpenXcom.
3) (OPTIONAL / lesser priority) We could make a sensible default bindings for some of the keys - but the UI already enables users to make their own in any case.
-
2) We need some kind of virtual keyboard for A) Save game naming (or, we could workaround this by auto-naming; the saves already have the in-game time stamped on them, so naming is no obligatory. Maybe we could have at least GEOSCAPE or BATTLESCAPE as an autoname?) and B) Base naming and C) (optional) soldier naming. Most of the game works without a keyboard, but some parts do use it.
The Dingoo port added an "arcade-style keyboard" (D-Pad for typing letters) which is enabled by setting "keyboardMode: 1" in the options.cfg. Maybe it would be useful for the GCW-Zero too?
-
Hello Wild Penguin.
Some months ago zear from GCW-Zero team asked me about my OpenXCom port. I said him that I had no free time to continue the work at that moment, as I was working on another projects. So I sent him my latest working code, as he told me he will work on that. Since then, I don't know how is his progress. Maybe you could try to contact him on dingoonity.org
Anyway, if you like to take a look, here's the files: https://dl.dropboxusercontent.com/u/5789679/OpenXcom-copy.tar.bz2
As SupSuper has said, the "arcade-style keyboard" is already working for name entry on GCW-Zero, the critical part there is the battle scene poor performance and the need of a proper mouse emulation through analog stick.
-
zear (https://openxcom.org/forum/index.php?action=profile;u=132) is also a member here and you can sometimes find him in IRC too.
Btw I've fixed the __NO_OPENGL flag so you can use it to completely disable OpenGL for devices that don't support it, since it's only needed for display filters anyways.