[Question] Platforming #8
Comments
|
Linux and Mac support will be amongst the first things to be added, besides known bugfixes from ioquake3. eXeC64 is currently working on CMake files https://github.com/eXeC64/OpenJK once we've got those, the real work can begin. If you've already forked, you'll want to merge to the latest version - the initial commit accidentally used the XBox version, which is bad. |
|
As a Linux user, I literally jumped up in excitement (and this was during one of my classes at school) when I heard the JK2/3 source was released. Linux support is definately good, and after looking through the source in an attempt to try and compile under Linux (which failed, tons of errors due to not being written for GCC) I noticed that the files between ioquake3 and JK were pretty much the same. Was I surprised? Not really, it's based on Quake III. However, ioquake has several desirable features that would be an excellent addition to OpenJK. Once support does come out, I'll definitely be a tester and maybe even do some modwork on my own fork. I'd personally like to make a Quake III <-> JK crossover mod. Then I will finally be able to murder singleplayer with a shotgun in hand. :D |
|
Quick Question: What technologies are you targeting implementing?
|
? OpenAL and OpenGL are already implemented, and SDL is Linux-only I believe. ioquake3 fixes are being applied too I think. |
|
The game currently uses OpenAL/ALUT and OpenGL, as well as native windows code. We'll probably keep the former while replacing the Windows stuff with SDL or SFML on other operating systems. |
|
@eezstreet SDL is cross-plattform. |
Correct, though one of our members has reservations about the Windows version of SDL and would prefer to keep the Windows version SDL-free. Who was that again? @Razish? Well, it could always be made optional in the CMake files. |
|
I personally think that keeping Windows SDL-free is a good idea aswell. |
|
Raz0r is concerned about overhead and bulk, while I'm concerned about mouse smoothing and event gobbling/debugging problems. Sent from my Windows Phone From: MazterQyoumailto:notifications@github.com I personally think that keeping Windows SDL-free is a good idea aswell. Reply to this email directly or view it on GitHub: |
|
I'd like to bring up the topic of mouse acceleration, specifically on OS X. Mouse acceleration on OS X is very slippery, meaning the cursor is really slow when moving the mouse slowly and it's really fast when you move the mouse quickly (I can go from one end of the screen to the other by moving about 1cm). Obviously this is awful for FPS games and the only solution I have been able to find is to use Controller Mate and create a linear acceleration curve for the game. This works well enough, but it has the side efect of changing the cursor speed throughout the whole game, including menus. Now, I like the OS X mouse acceleration, it's what I use for everyday work and it's what I got used to, it's just aiming in games that's awful with it. Here is my question: Would it be possible to create a "linear mouse fix" that's only applied while the player is aiming, but still keep the OS's native acceleration during menus and everything else? There was a similar discussion on the OpenMW forums: If it's not possible I'll stick with Controller Mate, but it would be great if you guys could have an option to get linear aiming regardless of what the OS cursor uses. |
|
I totally agree with that. |
|
I just forked and join the project (also JA Coders forum). I would like to help on Linux and Mac ports. |
|
I don't see why you would want to keep the windows version SDL free (SDL2, at least). It would make everything a lot simpler if the platform window and input abstraction is handled via SDL or something like it than if there were a bunch of #ifs involved. |
Yeah..except that input events are gobbled like Pac Man eating pellets.. |
|
I assume http://www.libsdl.org/docs/html/sdlwmgrabinput.html is On 6 April 2013 05:27, eezstreet notifications@github.com wrote:
Daniel Evans |
|
That's the main way of getting input, so no. Sent from my Windows Phone From: Daniel Evansmailto:notifications@github.com I assume this is On 6 April 2013 05:27, eezstreet notifications@github.com wrote:
Daniel Evans Reply to this email directly or view it on GitHub: |
|
On the note of audio, you're probably going to want to port the EAX audio to EFX, using AL Soft on all platforms (Creative's and Apple's OpenAL implementations are pretty awful, IMO). Not quite as big of a task as the SDL port work, but still pretty important to be feature-complete on every target OS. |
|
@danharibo I'm really the only one on the project who is for SDL even on windows (But also implement in_mouse 3 for raw) but nobody else is unfortunately =[ |
|
Well, it's usually better to use native stuff other than some ported libs... It's like comparing binaries compiled in Visual Studio and MinGW. In two words, the latter suck. Îòïðàâëåíî ñ iPad / Sent from iPad 07.04.2013, â 7:20, Ensiform notifications@github.com íàïèñàë(à):
|
|
So you think it'd be better to write your own shim for this piece of engine functionality and have to maintain separate codepaths for separate platforms in this codebase, instead of using a high-quality library that does the abstraction for you? How does any compiler stuff have anything to do with the matter at hand? It's like if I claimed crisps were my favourite salty snack and you'd come around and say "ice cream is better because it's got sugar in it". |
|
@meklu It's just that some team members have the opinion that some aspects of this "high-quality library" are fairly lacking on Windows. Personally, I have no idea, but I think they know what they're talking about. |
|
That's exactly what I meant. |
|
I just took a look at things and as per my assumptions, Valve uses SDL2 for the Windows builds of GoldSrc. If its mouse handling is good enough for the snobby CS 1.6 players, it ought to be good enough for everyone else as well. |
|
You could probably get away with having two input versions, as long as people want to maintain both. It looks silly in code, but it's not that big of a deal. |
|
Well to be honest I personally don't care what is going to be used, but as a developer of a JA-based project I want the compatibility with original JA files be preserved, and so it should look like original, because as I got the point of the project is to maintain the code in the way "fixes, porting, patches from ioq3 etc". No gameplay changes etc. |
|
I am willing to give SDL2 a shot. If it has the same input and window management bugs (on windows) that I've experienced in SDL 1.2, then SDL will remain a mac+linux backend only and we'll keep the existing native win32 code. |
|
That's probably the most sensible approach to this. |
|
I've forked as well this project. |
|
With SDL, if there's an issue on Windows you should be reporting it to the devs. They are professional game developers. Sam Latinga works at Valve software now and he's the primary SDL dev. The developers are very friendly and should be able to help you with any problems relating to performance etc. |
|
Again, if they fix it for SDL 2.0, it doesn't really matter to me. I don't speak for everyone, but Win32 is fine without SDL, so don't fix what ain't broken. Sent from my Windows Phone -----Original Message----- With SDL, if there's an issue on Windows you should be reporting it to the devs. They are professional game developers. Sam Latinga works at Valve software now and he's the primary SDL dev. The developers are very friendly and should be able to help you with any problems relating to performance etc. |
|
I was just made aware of GLFW, which would also work for window creation and input. But the whole window/input stuff is sufficiently modular that we could just have multiple drop-in solutions, selectable via CMake option, right? |
|
The input resides in the engine, window creation/graphics context resides in the modular renderer. |
|
Look what I found: https://plus.google.com/115670495573146293359/posts/MhEC1HMVxY2 |
|
@xycaleth Or at least see if we can get the source. |
|
We don't really need it. That's the JK2 engine, which we're not maintaining - JO will run under the OpenJK engine. |
|
Odd, I can't seem to get it to compile with cmake under GCC. Is it on a separate branch or is it not yet pulled? |
|
Are you on Windows? It should work with cmake on Windows. Support for other operating systems is not yet in. |
|
Oh, I was just confused by one of redsaurus's commits which fixed the particle colors on *nix systems, which led me to believe that it supported it currently. I did find exidl's branch and it seems he's getting it ready to push to the main repo since he merged his unix_sdl2 branch into master, so chances are redsaurus was fixing the particles based on exidl's branch like Razish was saying. |
|
Didn't want to open a new ticket, so I thought I'd ask this here. Could an Android port be a long-shot goal, or at least physically possible? The graphics are not excessively advanced and could be handled by a modern smartphone or tablet. |
|
I am not familiar with the code-base but I have seen a few snippets and it Then you need a modern opengl renderer which I believe is in the works or Once that is done you can mop up the easy stuff like handling the Android On 17 April 2013 01:19, cadika-orade notifications@github.com wrote:
Daniel Evans |
|
@cadika-orade |
|
Hmmm... RasPi with Oculus Rift. I can live with that. |
This doesn't make any sense, you still have to deal with the lack of On 17 April 2013 19:21, cadika-orade notifications@github.com wrote:
Daniel Evans |
|
What Direct3D? You can compile SDL for this most likely. |
|
@MazterQyou, WindowsRT has no support for OpenGL, so Direct3D is a requirement. |
|
@danharibo In general, an ARM port would be nice to have, PowerPC would be a good addition as well. |
|
OpenJK compiles for Linux and Mac now and runs fairly stable. Please create new issues for any problems as they arise. |
grabbing new changes to update my own personal fork
I've been looking for source code for years because I've been developing a project based off JA, and wrote to devs many times to ask for the source but eh, anyway, it's finally released.[/offtopic]
What I'm actually asking about is if OpenJK project is going to be compatible with other two popular platforms - Linux and OS X? This is a thing that have been stopping me from further development of my project for months.
I'd personally love to see support for latest GCC in Linux and Xcode 4.6.1 (possibly clang?).
And so I'd love to suggest that it would be a good idea to use CMake to generate project files for Linux and Mac.
P.S. I'm pretty sure there are many people who are ready to work on Linux stuff if OpenJK aims for cross-platform support. However, not sure if there are any people who are going to port this on Mac, and so I'd love to contribute to this project too by helping with cross-platform code porting. Though my C/C++ knowledge is not more than 'a bit below average', I can test building and fixing some stuff for Mac and Linux support since that one really bothers me.
Thanks in advance.
P.P.S. I am completely new to GitHub, just registered, forked this and posted here for the first time in 5 minutes while being asleep at nighttime. So please, if I posted this in wrong place, don't be angry and explain where to post it in, and I'll fix that.
The text was updated successfully, but these errors were encountered: