Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - sir_nacnud

Pages: [1] 2 3 4
1
Programming / Re: The yaml-cpp include dilemma
« on: November 29, 2011, 06:34:57 am »
Have you tried using angle brackets instead of quotes?  This is generally the approach when including system libraries.

Code: [Select]
#include <yaml-cpp/yaml.h>

See the distinction between angle bracket form and quoted form here: https://msdn.microsoft.com/en-us/library/36k2cdd4(v=vs.80).aspx

2
Builds & Ports / Re: Android Port
« on: November 29, 2011, 06:29:49 am »
I haven't been very active with the project lately.  Currently the Android port is pretty far behind the mainline of OpenXcom due to the introduction of wide characters, which native Android development now supports.

If you want to test it out, I can make an apk for you, but keep in mind the project at this point is mostly a proof of concept and not a polished application.

3
Suggestions / Re: opengl
« on: August 25, 2011, 07:08:21 am »
:o Shaders???  :o
Excuse me, but what for???
What's wrong with drawing quads with game graphics as textures? Even Z-buffer could be disabled, if tiles will be rendered in proper z-order (as they are at the moment).

"Texture sheet" actually called texture atlas, and can be used with classic quad-rendering tech. These atlases have to be built at graphics loading stage, because one GPU supports 4096x4096 texture maximum, another - 1024x1024, pre-building isn't an option. And... no need of massive texture transfer each frame!!!


Gosh...

Going shaders will instantly kill possibilitiy of porting application to other platforms, like ios or android...

iOS supports OpenGL ES 2.0 which supports a programmable pipeline (shaders) in addition to a fixed pipeline.  I don't know about Android, but I think it's phone dependent.

With the current version of OpenGL, 4.2, the programmable pipeline is the preferred method.  Most of the fixed pipeline functions are deprecated.  I'm not saying OpenXcom should use a shader based rendering method, just mentioning that it shouldn't be written off, as it is the current method for 3D graphics.

4
Suggestions / Re: opengl
« on: August 23, 2011, 06:01:21 am »
This is not really a suggestion, as I'm already working on it (in my own sandbox not in the official openxcom repository): people that are on IRC already know all of this, they are already totally bored with my rambling.
But I just wanted the forums opinion or comments too, regarding the implementation of it.

So the idea is to keep support for SDL, Pallettes, 8bit graphics, software blitting, 320x200 - the oldskool stuff.
But on top of that have the option for OpenGL, truecolor graphics, hardware blitting and higher resolutions.

Apart from the differences in intialisation, support for both opengl/sdl is done by abstracting the Surface class and creating two new implementations: SDLSurface and OGLSurface. The second one will load the surfaces as textures into video memory: blitting (and shading) surfaces will be done in video memory. (when it makes sense, because video memory has its limits)
New blitting functions, text & simple geometry rendering functions will have to be written in openGL versions.

I got the basic lines and pieces of code for the most part. I must give credit to the FIFE engine for it, as I take a lot of inspiration from there.
For testing I'm currently using UFO:TTS's graphics (which I converted to PNG, because I wanted to make sure SDL could handle that format also).

On the geoscape part we got another fun new toy to play with: drawing teh globe in opengl. In theory it would dramatically simplify the globe code (also the shading of the day/night cycle, which could be done simply by adding a rotating light to the scene), while dramatically increase the fps.
However I did not try anything on that front yet... it's just theory and ideas.


How are you going to handle palette rendering under OpenGL?  Building up a bunch of smaller buffers via software rendering, then uploading them as textures will be slow for higher resolutions.

When I was thinking about how to use OpenGL as a rendering backend, I found a couple of articles about talking about how to implement palette rendering.  The thought was you would have two textures, one that is 8 bit containing a color index for each texel, and the other of higher bit depth, containing your color values.  You then write a pixel shader that did the look up of the color index for the current texel in the color value texture.  I never did get around to implementing it, so I don't know how it would perform.

5
Programming / Re: command line params
« on: August 19, 2011, 03:43:19 am »
small patch that add (at last :> ) parsing args from command line.
supported commands:
-user lalala
-data kickicka
-displayWidth 444
-displayHeight 777
-fullscreen
-no-fullscreen

Just so you know, you can fork the project on github, commit your changes, and then submit a pull request.  Github is order's of magnitude better for getting your changes submitted, reviewed, and merged in, than a forum post  :P

6
Builds & Ports / Re: Android Port
« on: July 24, 2011, 08:09:50 pm »
sir_nacnud : did you check this out? https://github.com/PutzWorks/androidOpenXcom
Why would he not fork the project, as that seems to be easier to merge in updates, no?

Probaby, because one's done in C++ where as another is in Java?

Hehe, I even did not look that far. I wonder how all the SDL and YAML stuff works with java...  I wish this guy a lot of luck, because he'll need it :p

This is the first I have seen of this project.  I do wonder how he is handling SDL and YAML.  Maybe there are some Java libraries that can do palette rendering and YAML.  If he is calling SDL/YAML natively in Java, through JNI, he might as well be using the native version of OpenXcom, then it would pretty much be the same as my port.

7
Open Feedback / Re: OpenXcom NDS
« on: July 18, 2011, 06:51:09 am »
I don't think there would be any legal issues as it wouldn't be released as a product.  I know you can run homebrew apps on the DS, so that's probably how the port would work.

8
Open Feedback / Re: OpenXcom NDS
« on: June 16, 2011, 07:08:58 am »
This is an interesting idea.  The stylus would probably work pretty well for emulating mouse input.  The hardest part would probably be getting a port of SDL for the DS.  I did a quick google search and there were some results for a port of SDL to the DS, though I didn't dig too deep.

9
Programming / Re: Git and Eclipse
« on: March 16, 2011, 02:34:53 am »
Given that you are a Gentoo user (I used Gentoo for two years, now use Kubuntu), you should have no problem using git from the command line.  I do most of my git operations from the command line, but occasionally use GUI programs to get a visual representation of the repository.

The way Git works is it is a distributed revision control system, there is no central repository where the code lives.  Each developer has a full copy of the repository.  With this repository, you can push your changes to other developers, or pull their changes in.  Hopefully this isn't confusing, but GitHub takes this idea and introduces a central repository.  So when you create or fork a repository, you create a central repository.  Then when you clone this repository, you create a local repository.  So if you do a git commit, it just goes to your local repository.  You have to do a git push, to send your changes up to your repository on GitHub.

10
Offtopic / Re: the irony, openxcom makes me play less x-com
« on: March 11, 2011, 03:37:24 am »
After I discovered this place, I  started to play X-Com on PC and PSX version on my Nexus One.  ;D

How's the performance of the PlayStation emulator on your Nexus One?

11
Builds & Ports / Re: Android Port
« on: March 01, 2011, 03:50:44 am »
I also plan on adding dragging to certain aspects of the UI, like the globe on the Geoscape and probably the map on the Battlescape.

Some of that features probably could be merged back to pc openxcom as well. Btw, where you will be coding those? In your fork/branch on github or in another project?

Edit:

Hmm, i just found that project https://github.com/sirnacnud/openxcom-mine

Why another project? Why not fork of https://github.com/SupSuper/OpenXcom ?

I created it before the switch to GitHub.  That repository will be going away shortly, replaced by the fork I have here: https://github.com/sirnacnud/OpenXcom.  There is an android branch in this repository that I will be committing my changes to.

There are styluses adapted for capacitive touchsecreens. I don't think zooming buttons 4 times for large fingers will be fair enough, considering globe tiny 3x3 pixeled objects (ufos, crafts, bases/cities, etc) and battlescape tiles aren't capable to be enlarged for fingeraiming purposes.

Almost all new smart phones use capacitive touch screens, so I will be targeting finger input.  Most people don't  want to use a stylus anyways.  I am planning on increasing the area for things you can click on the globe.

12
Builds & Ports / Re: Android Port
« on: February 28, 2011, 06:35:34 am »
Just got sounds and music working!

Congratulation. Do you think the UI design of Pocket UFO is useful?

I checked it out on PC.  I thought the way they did the globe was interesting.  Overall, the UI seemed like it was supposed to be used with a stylus, rather than a finger.  I noticed buttons were still fairly small.  I will probably poke around with it some more.

Right now my plan with the android port is to try and keep the look consistent with OpenXcom, but improve the UI to be more finger friendly.  This will mainly involve increasing the size of the buttons and moving UI elements around to better suit finger use.  I also plan on adding dragging to certain aspects of the UI, like the globe on the Geoscape and probably the map on the Battlescape.

13
Builds & Ports / Re: Android Port
« on: February 28, 2011, 02:37:22 am »
Just got sounds and music working!

14
Suggestions / Re: Cloud Saving
« on: February 19, 2011, 07:26:46 am »
SDL has support for networking.  This is probably would be what you would use, given Windows uses it's own winsock API, where as Unix based systems use Berkeley sockets.

I think this might be a cool idea for mobile apps, like my android port.

15
Offtopic / Re: New sf theme
« on: February 12, 2011, 02:51:50 am »
Yeah I think the old theme looked better as well.  Another reason to switch to GitHub :)

Pages: [1] 2 3 4