Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Cross-Platform Development => Topic started by: Kromaatikse on March 06, 2012, 01:58:04 pm
-
I noticed some previous discussion about OpenGL ES, centred around Android and iOS. And yes, I saw the conclusions of those discussions: that the input methods normally available on those platforms are not suitable for a space fighter sim.
But what if I start talking about a proper Linux platform, where one can assume a proper sized screen and proper desktop input devices, yet where the graphics acceleration is provided by OpenGL ES (or ES2) instead of "classic" OpenGL? It's less powerful than today's desktop PCs, of course, but it compares very well to what was available at retail FS2's release.
I am of course talking about Raspberry Pi.
So I made sure that I could compile and run FSO with retail VPs on a more conventional Linux machine - which was surprisingly easy - an then started looking at what would be needed to convert it to GLES2.
Oh boy. The ancient and obsolete-in-GL-1.1-already glBegin/End paradigm is all over the place. Where did you guys learn your GL coding skills? Seriously. :nono:
So that's the first stage, and it can be done without breaking compatibility with anything whatsoever, and probably improving performance a bit while we're at it. I see that vertex arrays are already used in some places, but since GLES has completely dropped the Begin/End paradigm (and for good reason), they have to be used *everywhere*. Yes, even for single points or fullscreen quads - those are the easiest to convert, in fact, and I already refreshed my skills on the MVE cutscene player (which has the virtue of being the very first thing on screen, so ridiculously easy to test). Ideally we should also be using VBOs where practical, but that's not a necessity.
I wonder if we can get rid of some of the unnecessary and inefficient fixed-point arithmetic while we're at it. This game never (intentionally, anyway) ran on anything less than a Pentium Classic, which had a pretty good FPU already.
The next stage, assuming the target is GLES2, is to convert literally everything to shaders. GLES1 doesn't have shaders at all, which is a bit limiting, and all worthwhile hardware supports GLES2, so that's the obvious target. This is, however, the point where backwards compatibility with old desktop hardware (eg. original Radeon) that was perfectly capable of running retail FS2 starts to become a problem. Any thoughts on this would be interesting to hear. It should be possible to leave the fixed-functionality code in parallel, but then you have two code paths, one of which is likely to decay over time unless it is actively tested.
As part of converting everything to shaders, it's time to drop vertex arrays... what, didn't we just finish putting those in five minutes ago? Let me finish. Drop vertex arrays, normal arrays, colour arrays, texcoord arrays, all of them - and specify them as vertex attribute arrays instead. Vertex attributes are the correct way to do a fully shaded graphics pipeline, which avoids having to shoehorn everything into and out of the original fixed-function pipeline state. You guessed it, as part of the major API cleanup, GLES2 dropped that state, so vertex attributes are all there is. This requires a minor rewrite of all the shaders, BTW, but there at least we don't have to worry about backwards compatibility - desktop GL2 has vertex attributes, and anything not supporting GL2 doesn't run GL shaders at all. Also fortunately, replacing vertex arrays et al with vertex attribute arrays is a like-for-like replacement job, so very easy.
All of the above can be done on desktop GL on any already-supported platform. All of it is a good refactoring and cleanup operation *anyway*. Some of it might directly result in performance improvements due to coming up to date and being cleaner.
Once all of that is done, it should be reasonably straightforward to do the actual port to GLES2. It mostly involves hunting down uses of missing features and sorting out quirks (such as precision specifiers) of the smaller API. It also means arranging for a new context creation and possibly input method, which might involve work on SDL rather than FSO itself.
All in favour? :yes:
All against? :wtf:
-
:yes:
As far as:
Where did you guys learn your GL coding skills? Seriously.
Mom's basement. Dunno bout everybody else.
-
Where did you guys learn your GL coding skills? Seriously. :nono:
I have no GL coding skills, but i will learn it to review your patch !
-
wat.
I'm sorry if we've offended your sensibilities regarding the OpenGL code, but bear in mind the following:
1. FSO runs on a lot of hardware, with a lot of people still using OpenGL 2-level stuff (looking at you, intelgrated people)
2. A move toward a forward-compatible OpenGL3 implementation is planned, but won't be started until after 3.6.14 makes it out the door
3. Until quite recently, we did not have people on the team with the necessary skills to make such an effort
4. OpenGL 3, not ES, is our focus. While "portable" installations would be a nice thing to have, most of our users are on desktop or laptop PCs.
5. While we plan to remove the shader support for GL2-level hardware, the original fixed-function render path should stay intact (see above re: Intel users). We do not want to alienate people without pressing need.
-
Well, now that I've got your attention... ;)
Nearly all of what I posted above also applies to converting to GL3 Core Profile. You still need to eliminate Begin/End, convert everything to shaders and vertex attributes, and eliminate all other references to obsolete functionality. Only the final step, of downconverting to the GLES2 feature set, is eliminated.
Porting from GL3 Core to GLES2 should be relatively easy, since essentially the same design decisions and API culling occurred in each design - not surprising since they were done by the same group of people. IIRC, Khronos took over OpenGL responsibility once GLES2 was already established and becoming popular, and that's when GL3 began to take shape. If the GL3 conversion is done carefully, it should even be possible for GL3 and GLES2 support to coexist in the same code path without too many #ifdefs.
Not to mention that GL2.x supports almost everything that GL3 Core does. The problem with, ah, "Intelgrated" graphics is mostly due to performance, bugs and a few relatively minor missing features which are mandatory in GL3.
Maintaining separate code paths for old (FF) hardware and modern (fully shader based) hardware is fine by me, if that's what you are planning anyway. The main concern is avoiding bitrot in one or the other. I suggest doing the conversion away from Begin/End before splitting, though, since that loses you nothing and is particularly important on slower hardware.
And, in fact, I have a fairly good idea where the ubiquity of Begin/End comes from: NeHe. Once I learned enough to understand how graphics hardware really works, and looked back to see when vertex arrays were introduced - hint, it was long before PC 3D accelerators arrived - I seriously wondered why anyone bothered to teach Begin/End any more. Yet all the tutorials I could find started with that, and introduced vertex arrays as an "advanced technique" for performance optimisation. Only when GLES arrived and made vertex arrays mandatory did tutorials - and only those specifically for GLES - start to use them from the start.
And yet, if your head isn't already cluttered up with the Begin/End way of doing things, it's much easier to understand the GL as a whole and how vertex arrays fit into it. This is the beauty of GLES2, as it reveals the inherent conceptual simplicity of a modern graphics pipeline. Once you realise that models usually have a fixed number of vertices and thus memory management is a lot easier than you first thought, and you write a few helper functions to take care of some of the nastier boilerplate, and you write a few simple shaders to cover your basic rendering needs, you forget Begin/End ... until you run across it in someone else's code, and promptly start :banghead:.
It's like BASIC with GOSUB all over again, twenty or so years later. The only way to pass data into or out of a GOSUB routine is via global variables. I'm sure you all know what a crapshoot that is.
The truth is probably that the tutorial writers learned Begin/End first, for whatever reason, and didn't feel confident enough with C memory management to recommend vertex arrays as a starting point for anyone else. The fact is, Begin/End forces the GL to do the conversion and the memory management for you, only much less efficiently, because the hardware only works with arrays and the driver can't make any optimisations based on data probably remaining the same between frames. Specifying one vertex at a time only ever made sense with software rendering.
Finally, I agree that starting a major upheaval like this is best done after a release, rather than just before it. Perhaps some preliminary work can be done in a branch, as a proof of concept if nothing else.
-
How long do you think it would take to finish this endeavor?
-
More importantly, how much of that work are you willing to do yourself? I'm always happy to welcome aboard new coders who are willing to code for us. Not so happy with the "You're doing it all wrong, do it my way. It's better. I'll tell you all how to do it" kind.
I'm assuming you're the former but I've seen plenty of the latter before so it's worth asking before wasting any time. :)
-
Both good points. I'm still finding my way around the code, but at least it looks like nearly all the GL stuff is grouped together in one place, which definitely helps. There's currently a state manager and a standard vertex format for the FF paradigm and the textures, but no obvious equivalent management for the vertex buffers that already exist. Centralising that logic early on will definitely simplify matters.
So I don't know how long it will take, but it should take less than the average point release time of FSO in recent years. :lol:
I mentioned http://www.raspberrypi.org/ (http://www.raspberrypi.org/) before, as that's a project I'm fairly involved in already - I've dug up a lot of information, written test programs to tease out problems with SD cards for it, and even whipped up a basic Linux distro in a few days in order to encourage hardfloat versions of the graphics libraries (a big efficiency improvement) to be produced. There was a discussion about what games would be nice-to-haves on it, and FS2 came up very quickly indeed. And so here I am, essentially asking about the best direction to proceed to make it happen.
I could port it all myself, but the changes required are so extensive that the end result would not be mergeable with the main codebase afterwards. Knowing that work in a technically very similar direction is planned is thus very helpful, since we might be able to work together rather than at cross purposes.
Of course, since I have a fairly demanding (and semi related) day job, I don't have unlimited amounts of spare time to dedicate to the cause, but I can certainly chip in.
-
I'm not expecting you to give up bathing for FS2_Open. Just wanted to know you had a good reason to stick around. :)
-
Kromaatikse, please stay around and help SCP to implement OpenGL3. And ES2 while at it. Your efforts would be very much appreciated, at least if you're willing to get your own hands dirty. :)
-
All right, let's see what we can come up with.
So far, as mentioned, I've built SVN HEAD on Linux and proved that it works with retail data. I could also try it with some of the mediavps, although the machine I'm using for this is a bit weak - Atom+ION2. What else should I do to really get started?
-
This is really interesting, and beneficial.
Another open source game project I follow, 0AD, has recently done a rewrite to support GLSL and ES.
While it did allow cross compiling and basic running on Android - which is explicitly still a hobby, and not a platform that 0AD will target releases for yet - the code improvements have helped on standard OpenGL with performance.
So a big win to seek out compatability and refactoring for ES.
-
Interestingly, cross-compiling won't be necessary for this port, even though I have an ARM based machine in mind. Because it's meant to be a full Linux computer, it is a simple matter to install and use all of the necessary build tools directly on it (in the extreme case by simply installing Gentoo). It will just take a bit longer to build than on a standard desktop machine.
-
You could set up cross-compiling distcc to speed things up maybe.
-
I'll cross that bridge when I come to it - my Raspberry Pi hardware hasn't arrived yet, and there is a lot of work to do on the desktop side first, for which the Atom is sufficient. In any case I have a second ARM based machine which is more powerful (dual Cortex-A9 versus single ARM11), so plain distcc would still work fine.
It strikes me that an early need will be for an upgraded state manager that, as well as textures and FF state, can keep track of VBOs and shaders, and be capable of storing entire state vectors so that setup code doesn't need to be duplicated everywhere. This, I think, would also help to hide and ease the differences between legacy FF-style state and modern vertex attributes.
Such a manager could provide what's known as a "stateless rendering API". This means that all the information needed to render anything is provided explicitly during the draw call, using state objects that are set up by the caller and can be kept between frames, and the (stateful) GL is manipulated behind the scenes to the minimum extent necessary to set up the correct state for that draw event. This is a useful idea mainly because GL API calls are pretty expensive - I recently measured a GLES2 implementation that was able to do maybe 10,000 APi calls per second, versus maybe ten million vertices per second.
The alternative is that we do local, straightforward conversions. This might mean that we still have to find somewhere to allocate and fill a vertex array or VBO beforehand. Things might get even hairier once we need to map vertex attributes for a given shader together - which BTW we should try to do using enumerated constant lookups into a cache, not strings all the time. This latter part is a really good argument for proper state management code, even if only for that specific subproblem.
Or maybe I have too many ideas and not enough reading of the code to make them concrete yet. :nervous:
-
I wonder if we can get rid of some of the unnecessary and inefficient fixed-point arithmetic while we're at it.
Can you be more precise on that ?
What code parts are you specifically referring to ?
-
While playing with the cutscene code, I noticed that it was using glVertex2i and a nasty conversion macro to get there from numbers in some sensible coordinate system. It's entirely possible that that is already an exception to normal practice; if so I'll be quite happy. The cutscene code is not performance critical and so might have escaped cleanup applied elsewhere.
I really need to sit down and digest this code properly.
-
Okay, it's not as bad as I feared since integer vertices only seem to get used for 2D UI and cutscene stuff. But there's still a lot of fl2i and i2fl use (they are just casts, but casts of this type are expensive) which is probably excessive.
As rules of thumb:
Use integers for things that are fundamentally discrete, such as handles or indices.
Use small integers for compact storage of static bulk data such as textures.
Use floats for everything else. They are not performance expensive when you have an FPU, which we do on every supported platform all the way back to retail era.
Use ceil, floor et al instead of casting to int whenever possible. This can be a big win. Only cast to int when inevitable, eg when an array index will result. Try to keep such things rare.
OpenGL uses floats internally for almost everything (even colours with modern shaders). Therefore avoid making it perform extra conversions, by giving it floats whenever you conveniently can. This doesn't mean you have to unpack textures.
-
Okay, now that it's technically the weekend, I've had a chance to sit down and really investigate - starting with a profile run using Callgrind (part of Valgrind). This is not the most efficient profiler ever - on my Atom box it reminded me of playing Elite on original hardware - but it doesn't miss a thing, and is excellent for getting accurate call counts. The noble sacrifice of the crew of the Aquitaine shall not be in vain.
Those call counts tell me that gr_opengl_render_buffer() is called about 240 times per frame (for the mission I tested) on average. This is about 20 times per model, and there is often more than one model per ship (I'm guessing for moving turrets). And this is on retail data, where the models and the rendering pipeline must be much simpler than on the enhanced stuff. This in itself is not too shocking - provided it is a reasonably efficient function.
But gr_opengl_render_buffer() always calls one of two massive catch-all rendering functions, both of which set up a lot of state, draw one vertex buffer, then carefully tear it all down again. This is a hilariously inefficient way of doing things - the only possibilities of being worse would be if it still used Begin/End, or decided to upload the textures anew every time, or something ridiculous like that. It even looks up the shader attributes using string comparisons. :shaking:
This is what a state manager is supposed to take care of for you. A state manager exists in the code, but it doesn't really do anything useful except for major state like textures - it's just another layer of abstraction. :rolleyes:
Accordingly, the second thing on my todo list is to implement a proper state manager that is actually useful. The first thing on the list is still to do basic Begin/End to vertex array conversions, probably picking out a few unnecessary integer conversions in the process. Once those two things are complete, it should by then be fairly clear how to proceed further.
-
Looking forward to it.
-
More stuff from profiling: rendering text in the HUD is pretty expensive. Not surprising since it uses Begin/End...
It doesn't really dominate the CPU load of rendering each frame, but it does show up pretty well despite the sheer inefficiency of the main rendering path.
-
Slightly off-topic:
I need to learn OpenGL and OpenGLES. Where do you suggest I go for a good tutorial?
(My primary framework is Qt, which has some modern tutorials but they don't go into much detail and most of the other ones I've seen are the old glBegin/end style.)
-
Well, I stopped reading tutorials after a while and started reading specs.
But you need to know what specs to read and what concepts to have in mind first. For that, I suggest this: http://www.learnopengles.com/android-lesson-one-getting-started/
That tutorial targets Android and OpenGL ES2. Most of the code is in Java and there are some Android-specific parts to it. If you are developing on another platform (eg. plain Linux, or Windows) then you will need to look up how to do several things, such as obtain a GLES2 context and manipulate matrices, on your particular platform. However, all of the concepts, actual GL calls and GLSL code should be portable. Most of them also port neatly to modern versions of desktop OpenGL.
You might also find the Khronos reference cards useful, eg. http://www.khronos.org/opengles/sdk/docs/reference_cards/OpenGL-ES-2_0-Reference-card.pdf These reference cards have references back to sections of the full spec document.
ETA: http://www.g-truc.net/project-0026.html#menu is also a good set of examples, albeit with minimum explanation. Download the latest one, sort by name and start from the top.
-
Okay, first patch that I'm happy with, dealing with just the MVE cutscene player. This is essentially a blueprint for all the other Begin/End elimination.
The patch actually does several related things at once:
1) Converts an instance of Begin/End to a vertex array call.
2) Moves the vertex array setup to a setup function, and the teardown to a teardown function. (These already existed, conveniently.)
3) Converts the QUADS format into TRIANGLE_STRIP format, since QUADS and QUAD_STRIP are unavailable in ES or GL3 Core. For a single quad like this, just swap the last two vertices. For multiple quads that are not already in a strip, more effort is required.
4) Removes a use of fl2i(), replacing it with a rounding function. This function might possibly be missing on Windows, in which case it can be implemented with ceilf(X - 0.5f) or floorf(X + 0.5f).
[attachment deleted by a ninja]
-
Second patch, doing essentially the same thing to the Ogg cutscene player. Most of the intervening time was spent waiting for the FSO installer to download everything so that I could test it.
[attachment deleted by a ninja]
-
Forgive me if this was covered in the initial post, but what kind of performance increases would this entail? More importantly, what kind of new features would be possible if we switch to ES or GL3?
-
sigtau, I don't know if we'd know until it's done, but if the state manager can be improved as much as it sounds, I'm guessing a very substantial increase.
-
I can't give hard numbers for performance improvements, partly because it will vary wildly by what machine you have. I have however seen comments that "it should be faster than this", and this would be a definite step in that direction. The initial step of excising the Begin/End paradigm - made obsolete by GL 1.1 for crying out loud - will not have any compatibility effects - this is pure win.
Of course, the patches I've already done and posted will have zero measurable performance impact. They apply to a part of the code that is not performance limited at all. There are other, more important reasons for dealing with it though.
Looking at my profile with retail data, I see that roughly all of the functions that use glBegin/glEnd are called at least once per frame and usually a lot more than that. This corresponds to many many unnecessary GL API calls per frame. Each GL API call is in itself an overhead that it is wise to avoid.
The "new features" that we should expect are compatibility with newer and more interesting platforms. For example, MacOS X will not add support for new GL features to the "compatibility profile" implementation it supports. New features will therefore appear only in the "core profile" implementation. Therefore in order for the Mac port to keep up with other platforms in terms of rendering features, the whole engine has to be made compatible with Core Profile, which happily is also a long way towards GLES2 compatibility.
And, of course, OpenGL ES2 support opens up non-x86-based Linux platforms, particularly the Raspberry Pi that I'm planning to target once the cleanup operation is done. ARM based platforms generally don't come with PC-type graphics cards, and therefore don't see any need to support "legacy" OpenGL since it doesn't provide any features that mobile games and navigation apps can't easily do without. An, if they *do* eventually move on, it will likely be to GL3 Core Profile, not back to legacy GL.
The later stages of the conversion have the *potential* to cause compatibility problems with older GL versions, specifically pre-2.0. I think that this can be dealt with by the new state manager I proposed - by knowing what sort of rendering is to be done, it can adapt to shader mode (using Core Profile compatible calls exclusively) or fixed-function mode (using legacy calls exclusively). The rest of the rendering code would then be decoupled from that decision to the extent possible - obviously some effects are not available without shaders.
-
Okay, here's patch 3 with conversion of three heavily-used functions in opengldraw.cpp. I've tested this briefly, it could do with more even though it's ObviouslyCorrect (tm).
There is more state manipulation than I really like going on here, and that accounts for some of the code expansion, but that will be cleaned up when the state manager goes in.
[attachment deleted by a ninja]
-
mveplayer.cpp
..\..\code\cutscene\mveplayer.cpp(483) : error C3861: 'roundf': identifier not found
..\..\code\cutscene\mveplayer.cpp(484) : error C3861: 'roundf': identifier not found
..\..\code\cutscene\mveplayer.cpp(487) : warning C4244: '=' : conversion from 'int' to 'float', possible loss of data
..\..\code\cutscene\mveplayer.cpp(488) : warning C4244: '=' : conversion from 'int' to 'float', possible loss of data
..\..\code\cutscene\mveplayer.cpp(615) : warning C4244: 'argument' : conversion from 'float' to 'int', possible loss of data
..\..\code\cutscene\mveplayer.cpp(615) : warning C4244: 'argument' : conversion from 'float' to 'int', possible loss of data
..\..\code\graphics\gropengldraw.cpp(512) : warning C4244: '=' : conversion from 'int' to 'GLfloat', possible loss of data
..\..\code\graphics\gropengldraw.cpp(513) : warning C4244: '=' : conversion from 'int' to 'GLfloat', possible loss of data
..\..\code\graphics\gropengldraw.cpp(517) : warning C4244: '=' : conversion from 'int' to 'GLfloat', possible loss of data
..\..\code\graphics\gropengldraw.cpp(518) : warning C4244: '=' : conversion from 'int' to 'GLfloat', possible loss of data
..\..\code\graphics\gropengldraw.cpp(522) : warning C4244: '=' : conversion from 'int' to 'GLfloat', possible loss of data
..\..\code\graphics\gropengldraw.cpp(523) : warning C4244: '=' : conversion from 'int' to 'GLfloat', possible loss of data
..\..\code\graphics\gropengldraw.cpp(530) : warning C4244: '=' : conversion from 'int' to 'GLfloat', possible loss of data
..\..\code\graphics\gropengldraw.cpp(531) : warning C4244: '=' : conversion from 'int' to 'GLfloat', possible loss of data
..\..\code\graphics\gropengldraw.cpp(946) : error C2057: expected constant expression
..\..\code\graphics\gropengldraw.cpp(946) : error C2466: cannot allocate an array of constant size 0
..\..\code\graphics\gropengldraw.cpp(946) : error C2133: 'vertPos' : unknown size
..\..\code\graphics\gropengldraw.cpp(947) : error C2057: expected constant expression
..\..\code\graphics\gropengldraw.cpp(947) : error C2466: cannot allocate an array of constant size 0
..\..\code\graphics\gropengldraw.cpp(947) : error C2133: 'vertCol' : unknown size
..\..\code\graphics\gropengldraw.cpp(1043) : error C3861: 'glClientActiveTexture': identifier not found
..\..\code\graphics\gropengldraw.cpp(1047) : error C3861: 'glClientActiveTexture': identifier not found
..\..\code\graphics\gropengldraw.cpp(1062) : error C3861: 'glClientActiveTexture': identifier not found
In addition to your anticipated roundf incompatibility on Windows, which we can probably handle with a macro or something, I also got some other errors, attempting to compile all three patches at one time on VS 2008. The rest were in the last patch it looks like. Some of those warnings might have already been there. I applied the patches to Antipodes, as it's what I've been testing with the most lately. They applied cleanly.
-
Ugh, looks like your compiler doesn't have support for variable-sized local arrays. I thought those were well supported by now - but then again, roundf() is also a C99 standard function, which means that Windows is already a decade out of date in that respect.
I'll have a look at another way of doing it later.
-
Right, it seems I forgot that there are syntax features in C99 but not C++, as well as library features. VLAs are one of those, but g++ accepts a union of C99 and C++ features by default. Visual Studio does not support C99 at all except for a few isolated features.
To avoid such problems in future, I suggest adding -ansi to the g++ command options.
-
Okay, here's patch 3 with conversion of three heavily-used functions in opengldraw.cpp. I've tested this briefly, it could do with more even though it's ObviouslyCorrect (tm).
There is more state manipulation than I really like going on here, and that accounts for some of the code expansion, but that will be cleaned up when the state manager goes in.
Compiles cleanly here on LLVM 3.1 (Xcode 4.3.1, OS 10.7)
-
Ugh, looks like your compiler doesn't have support for variable-sized local arrays. I thought those were well supported by now - but then again, roundf() is also a C99 standard function, which means that Windows is already a decade out of date in that respect.
I'll have a look at another way of doing it later.
How about using C++, have you thought of that?
-
Yeah, there's some rules we are still going to have to follow. Windows is still our primary platform, as most of the tools are on it only still, if nothing else. FRED has to be compiled with the MFCs included with Visual Studio for the time being, so switching to another compiler on Windows isn't likely any time soon. It's also a rather good IDE, aside from its falling C standards supports. But the C++0x support is pretty good in 2010, although we do still try to support all the way back to VC6. So if this is possible sticking to older features of C/C++, it'll probably make everyone's lives easier if nothing else.
-
Well, this sucks. Bear in mind however that as far as G++ is concerned, VLAs *are* part of (extended) C++, and really should not be difficult to implement since they are mostly syntactic sugar for alloca().
Forgive me for not being intimately familiar with Visual Studio's failings. I very rarely write anything for Windows, and when I do I use MinGW for maximum familiarity.
Using std::vector would unfortunately involve at least one malloc/free pair behind the scenes. This is really not as efficient as I would like. Therefore I have *not* used the canonical C++ way of doing this.
Instead I converted the code to explicitly use alloca() - which is internally just stack pointer manipulation and thus guaranteed to be fast. The result looks ugly in source (due to having to specify the type multiple times) but should be pretty clean in machine code.
Revised patch attached.
[attachment deleted by a ninja]
-
Tried this one on VC6. Only issue there seems to be that alloca() isn't supported on that compiler. As far as I can tell, it's not part of any standard, ANSI or otherwise. This may not have to be a concern, we'll see.
-
Works fine on 2008 though. But can we get some explicit casts to get rid of some of those warnings?
As far as VLAs vs alloca vs std::vector, from what I've read, VLAs should only be used for small data allocations, and if it is going to be small, why not make it static? And if it's going to be larger, are we sure that stack allocation vs heap is the best idea?
I switched the roundf() calls to ceil(X - 0.5f) and all worked fine with the mveplayer patch too. Think roundf is any faster in machine code than the ceil() call, or would it make sense in this case to just replace it with the more available call? We could macro it if the benefit would be worth it.
-
The conversion warnings don't show up at all on G++. I'll have to dig deeper to try and match the warnings it can produce with what your compiler does.
Meanwhile I'm dealing with a MBP battery that just started bulging. Fun fun fun. :ick:
-
I might try to see if I can fix the warnings with casts on my end and come up with an updated patch or something, if I have time. Really busy couple of weeks coming up though.
-
Looks like -Wconversion should do the trick provided a new enough version of G++ is in use. I'll try that tonight.
Meanwhile I had a quick look at apitrace v3 which looks very promising. Progress towards less API calls per frame should be quite visible in that.
-
Was about to make an "are you insane? my old Intel POS only goes up to GL 1.4" post...
But now that I look at the reference pages I see that glVertexPointer, etc. are from GL 1.1, so you're good :P
-
Indeed, it is the vertex *attribute* pointers that only come in with shader support.
Those will come later, at which point it will be necessary to explicitly add compatibility code for GL 1.x.
I have a test machine or two that I can fit with an original Radeon (supporting GL 1.3) to make sure that sort of thing continues to work.
-
Real Life got in the way for a while, but I'm getting back into this again.
Eventually the text rendering code is going to need more cleanup, but for the moment I've just fixed the conversion warnings. I'm going to try to convert a few extra functions to vertex arrays for the next patch too.
-
Any update on this?
There is now one more reason for it... http://apc.io/about/
-
Real Life got in the way again. I've had to put most of my mental energy into a customer project, and the rest into resolving a couple of computer failures at home.
And I still haven't got my Raspberry Pi. The distributor as deigned to take my card details for it though, so it shouldn't be *that* far off.
No doubt once I get time to look at this again, I'll have to merge some upstream code into it first.
-
Good to hear from you, Kromaatikse. I was concerned that you'd lost interest.
-
I shall be getting my Raspberry Pi by the end of the month, if you require any testing, nightly builds or if there's anything I can help with, I would be glad to be of assistance :)
-
I shall be getting my Raspberry Pi by the end of the month, if you require any testing, nightly builds or if there's anything I can help with, I would be glad to be of assistance :)
I'm sure that would be much appreciated.
-
As it happens, I picked mine up from the post office today.
A second tester is a good thing though, especially if you use a different distro.
-
i intend to get one at some point, when im not using it for electronics projects i can always do testing. of course that could be months off from now.
that said how well will the game code run with a risc architecture? will a 700 mhz cpu and 256 mb of ram be enough? probibly will want an optimized set of media vps, with models and textures optimized for low end (but not antique) hardware such as this.
-
make that a 3rd tester when my Pi arrives - scheduled for the end of June :)
-
Given that a 700MHz Pentium-3 and a Rage128 was a high-end laptop spec around the time of retail release, and a 500MHz PowerPC G3 (RISC) was still considered faster than that... The ARM11 core in the Raspberry Pi is not as powerful as a G3, but it's not total crap either, and at least has a competent FPU.
We'll see. There's still a lot of work to do, but it will definitely be sensible to start with retail level graphics and then work up, mostly because of the RAM limitation.
Incidentally, I managed to extract a decent Pentium-3 based laptop (a ThinkPad, no less) from the office scrap pile a while ago, so I should be able to verify running the real retail code on that using an appropriate version of Windoze. Probably the limitation would be the Rage128, which is a lot slower than what the Raspberry Pi has. As an idea of just how high-end this laptop was at the time, it even has a USB port, so I can plug in my joystick!
-
yea, i remember the first time i ran the freespace 2 demo, on my old 120 mhz pentium machine, with 12 mb ram and a voodoo banshee card. ultimately i believe i ran the full version of the game on a 500 mhz pentium 3 (i think), 128 mb ram, and a voodoo 3 3500. im pretty sure its enough to run vanilla data (which iirc was not opengl optimized, as glide and d3d were the prime targets at the time). and that was the retail pre-scp engine, not the current iteration of the source which has by far a larger amount of stuff in it. ive been reading the spec sheet for the arm11 processor, and it has some advantages, it gets over the ****ing von neuman bottleneck for example.
-
i've ran FS2 on a pentium 166 mmx, 128MB RAM, Voodoo2 8MB on top of a S3 Virge DX/GX
it was the only pc i had back then, and yes, the game ran smoothly on that. in glide mode however, not DX. DX always had some awful visual artifacting on the V2.
-
...it gets over the ****ing von neuman bottleneck for example.
I don't see how, unless you mean the caches that every CPU since the 68030 has had to some extent. The RAM is often very close to the CPU these days (and the R-Pi uses package-on-package to maximise that), but the bottleneck still exists.
The nearest thing to a solution I've yet seen is the layout of a modern high-end graphics card, which uses many narrow RAM channels in parallel, gives each of them a separate L2 cache, and pipelines the shader engines so insanely deeply that the latency can be completely hidden in many cases. But it's still possible to run even one of those monsters in a RAM bandwidth starved mode.
-
Before I forget, here's a combined patch of the stuff in this thread, based on current trunk and with the post processing code adapted to use it as well:
Index: cutscene/mveplayer.cpp
===================================================================
--- cutscene/mveplayer.cpp (revision 8833)
+++ cutscene/mveplayer.cpp (working copy)
@@ -66,12 +66,13 @@
void *g_vBackBuf1, *g_vBackBuf2;
ushort *pixelbuf = NULL;
static GLuint GLtex = 0;
-static GLint gl_screenYH = 0;
-static GLint gl_screenXW = 0;
+static GLfloat gl_screenYH = 0;
+static GLfloat gl_screenXW = 0;
static GLfloat gl_screenU = 0;
static GLfloat gl_screenV = 0;
+static GLfloat glVertices[4][4] = {{0}};
static int g_screenWidth, g_screenHeight;
-static int g_screenX, g_screenY;
+static float g_screenX, g_screenY;
static int g_truecolor = 0;
static ubyte g_palette[768];
static ubyte *g_pCurMap = NULL;
@@ -478,12 +479,12 @@
}
if (mve_scale_video) {
- g_screenX = ((fl2i(gr_screen.max_w / scale_by + 0.5f) - g_width) / 2);
- g_screenY = ((fl2i(gr_screen.max_h / scale_by + 0.5f) - g_height) / 2);
+ g_screenX = ((ceil((gr_screen.max_w / scale_by) - 0.5f) - g_width) / 2);
+ g_screenY = ((ceil((gr_screen.max_h / scale_by) - 0.5f) - g_height) / 2);
} else {
// centers on 1024x768, fills on 640x480
- g_screenX = ((gr_screen.max_w - g_width) / 2);
- g_screenY = ((gr_screen.max_h - g_height) / 2);
+ g_screenX = ((float)(gr_screen.max_w - g_width) / 2.0f);
+ g_screenY = ((float)(gr_screen.max_h - g_height) / 2.0f);
}
// set additional values for screen width/height and UV coords
@@ -494,6 +495,32 @@
gl_screenU = i2fl(g_width) / i2fl(wp2);
gl_screenV = i2fl(g_height) / i2fl(hp2);
}
+
+ glVertices[0][0] = g_screenX;
+ glVertices[0][1] = g_screenY;
+ glVertices[0][2] = 0;
+ glVertices[0][3] = 0;
+
+ glVertices[1][0] = g_screenX;
+ glVertices[1][1] = gl_screenYH;
+ glVertices[1][2] = 0;
+ glVertices[1][3] = gl_screenV;
+
+ glVertices[2][0] = gl_screenXW;
+ glVertices[2][1] = g_screenY;
+ glVertices[2][2] = gl_screenU;
+ glVertices[2][3] = 0;
+
+ glVertices[3][0] = gl_screenXW;
+ glVertices[3][1] = gl_screenYH;
+ glVertices[3][2] = gl_screenU;
+ glVertices[3][3] = gl_screenV;
+
+ glVertexPointer(2, GL_FLOAT, sizeof(glVertices[0]), glVertices);
+ glTexCoordPointer(2, GL_FLOAT, sizeof(glVertices[0]), &(glVertices[0][2]));
+
+ glEnableClientState(GL_VERTEX_ARRAY);
+ glEnableClientState(GL_TEXTURE_COORD_ARRAY);
}
return 1;
@@ -579,24 +606,12 @@
if (gr_screen.mode == GR_OPENGL) {
glTexSubImage2D(GL_state.Texture.GetTarget(), 0, 0, 0, g_width, g_height, GL_BGRA, GL_UNSIGNED_SHORT_1_5_5_5_REV, pixelbuf);
- glBegin(GL_QUADS);
- glTexCoord2f(0, 0);
- glVertex2i(g_screenX, g_screenY);
-
- glTexCoord2f(0, gl_screenV);
- glVertex2i(g_screenX, gl_screenYH);
-
- glTexCoord2f(gl_screenU, gl_screenV);
- glVertex2i(gl_screenXW, gl_screenYH);
-
- glTexCoord2f(gl_screenU, 0);
- glVertex2i(gl_screenXW, g_screenY);
- glEnd();
+ glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
} else {
// DDOI - This is probably really fricking slow
int bitmap = bm_create (16, g_screenWidth, g_screenHeight, pixelbuf, 0);
gr_set_bitmap (bitmap);
- gr_bitmap (g_screenX, g_screenY, true);
+ gr_bitmap ((int)g_screenX, (int)g_screenY, true);
bm_release (bitmap);
}
@@ -779,6 +794,9 @@
void mve_shutdown()
{
if (gr_screen.mode == GR_OPENGL) {
+ glDisableClientState(GL_VERTEX_ARRAY);
+ glDisableClientState(GL_TEXTURE_COORD_ARRAY);
+
if (mve_scale_video) {
glMatrixMode(GL_MODELVIEW);
glPopMatrix();
Index: cutscene/oggplayer.cpp
===================================================================
--- cutscene/oggplayer.cpp (revision 8833)
+++ cutscene/oggplayer.cpp (working copy)
@@ -50,6 +50,7 @@
static GLint gl_screenXW = 0;
static GLfloat gl_screenU = 0;
static GLfloat gl_screenV = 0;
+static GLfloat glVertices[4][4] = {{0}};
// video externs from API graphics functions
extern void opengl_tcache_get_adjusted_texture_size(int w_in, int h_in, int *w_out, int *h_out);
@@ -535,6 +536,32 @@
vglUniform1iARB( vglGetUniformLocationARB(shader_id, "utex"), 1 );
vglUniform1iARB( vglGetUniformLocationARB(shader_id, "vtex"), 2 );
}
+
+ glVertices[0][0] = (GLfloat)g_screenX;
+ glVertices[0][1] = (GLfloat)g_screenY;
+ glVertices[0][2] = 0.0f;
+ glVertices[0][3] = 0.0f;
+
+ glVertices[1][0] = (GLfloat)g_screenX;
+ glVertices[1][1] = (GLfloat)gl_screenYH;
+ glVertices[1][2] = 0.0f;
+ glVertices[1][3] = gl_screenV;
+
+ glVertices[2][0] = (GLfloat)gl_screenXW;
+ glVertices[2][1] = (GLfloat)g_screenY;
+ glVertices[2][2] = gl_screenU;
+ glVertices[2][3] = 0.0f;
+
+ glVertices[3][0] = (GLfloat)gl_screenXW;
+ glVertices[3][1] = (GLfloat)gl_screenYH;
+ glVertices[3][2] = gl_screenU;
+ glVertices[3][3] = gl_screenV;
+
+ glVertexPointer(2, GL_FLOAT, sizeof(glVertices[0]), glVertices);
+ glTexCoordPointer(2, GL_FLOAT, sizeof(glVertices[0]), &(glVertices[0][2]));
+
+ glEnableClientState(GL_VERTEX_ARRAY);
+ glEnableClientState(GL_TEXTURE_COORD_ARRAY);
}
if(!use_shaders && tinfo->frame_height > 450) {
mprintf(("VIDEO: No shader support and hd video is beeing played this can get choppy."));
@@ -549,6 +576,9 @@
}
if (gr_screen.mode == GR_OPENGL) {
+ glDisableClientState(GL_VERTEX_ARRAY);
+ glDisableClientState(GL_TEXTURE_COORD_ARRAY);
+
if (scale_video) {
glMatrixMode(GL_MODELVIEW);
glPopMatrix();
@@ -680,19 +710,8 @@
} else {
glTexSubImage2D(GL_state.Texture.GetTarget(), 0, 0, 0, g_screenWidth, g_screenHeight, GL_BGR, GL_UNSIGNED_BYTE, pixelbuf);
}
- glBegin(GL_QUADS);
- glTexCoord2f(0, 0);
- glVertex2i(g_screenX, g_screenY);
- glTexCoord2f(0, gl_screenV);
- glVertex2i(g_screenX, gl_screenYH);
-
- glTexCoord2f(gl_screenU, gl_screenV);
- glVertex2i(gl_screenXW, gl_screenYH);
-
- glTexCoord2f(gl_screenU, 0);
- glVertex2i(gl_screenXW, g_screenY);
- glEnd();
+ glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
}
Mouse_hidden = 1;
gr_flip();
Index: graphics/gropengldraw.cpp
===================================================================
--- graphics/gropengldraw.cpp (revision 8833)
+++ graphics/gropengldraw.cpp (working copy)
@@ -59,6 +59,29 @@
gr_line(x, y, x, y, resize);
}
+inline void opengl_draw_textured_quad(
+ GLfloat x1, GLfloat y1, GLfloat u1, GLfloat v1,
+ GLfloat x2, GLfloat y2, GLfloat u2, GLfloat v2 )
+{
+ GLfloat glVertices[4][4] = {
+ { x1, y1, u1, v1 },
+ { x1, y2, u1, v2 },
+ { x2, y1, u2, v1 },
+ { x2, y2, u2, v2 }
+ };
+
+ glVertexPointer(2, GL_FLOAT, sizeof(glVertices[0]), glVertices);
+ glTexCoordPointer(2, GL_FLOAT, sizeof(glVertices[0]), &(glVertices[0][2]));
+
+ glEnableClientState(GL_VERTEX_ARRAY);
+ glEnableClientState(GL_TEXTURE_COORD_ARRAY);
+
+ glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
+
+ glDisableClientState(GL_VERTEX_ARRAY);
+ glDisableClientState(GL_TEXTURE_COORD_ARRAY);
+}
+
void opengl_aabitmap_ex_internal(int x, int y, int w, int h, int sx, int sy, bool resize, bool mirror)
{
if ( (w < 1) || (h < 1) ) {
@@ -120,20 +143,8 @@
GLboolean cull_face = GL_state.CullFace(GL_FALSE);
- glBegin(GL_QUADS);
- glTexCoord2f(u0, v1);
- glVertex2f(x1, y2);
+ opengl_draw_textured_quad(x1,y1,u0,v0, x2,y2,u1,v1);
- glTexCoord2f(u1, v1);
- glVertex2f(x2, y2);
-
- glTexCoord2f(u1, v0);
- glVertex2f(x2, y1);
-
- glTexCoord2f(u0, v0);
- glVertex2f(x1, y1);
- glEnd();
-
GL_state.CullFace(cull_face);
GL_CHECK_FOR_ERRORS("end of aabitmap_ex_internal()");
@@ -318,6 +329,7 @@
opengl_aabitmap_ex_internal(dx1, dy1, (dx2 - dx1 + 1), (dy2 - dy1 + 1), sx, sy, resize, mirror);
}
+struct v4 { GLfloat x,y,u,v; };
void gr_opengl_string(int sx, int sy, const char *s, bool resize)
{
@@ -328,6 +340,10 @@
int x1, x2, y1, y2;
float u_scale, v_scale;
+ // conversion from quads to triangles requires six vertices per quad
+ struct v4 *glVert = (struct v4*) alloca(sizeof(struct v4) * strlen(s) * 6);
+ int curChar = 0;
+
if ( !Current_font || (*s == 0) ) {
return;
}
@@ -350,7 +366,7 @@
bw = i2fl(ibw);
bh = i2fl(ibh);
-
+
// set color!
if (gr_screen.current_color.is_alphacolor) {
glColor4ub(gr_screen.current_color.red, gr_screen.current_color.green, gr_screen.current_color.blue, gr_screen.current_color.alpha);
@@ -384,9 +400,6 @@
GLboolean cull_face = GL_state.CullFace(GL_FALSE);
- // start rendering...
- glBegin(GL_QUADS);
-
// pick out letter coords, draw it, goto next letter and do the same
while (*s) {
x += spacing;
@@ -482,22 +495,43 @@
u1 = u_scale * (i2fl((u+xd)+wc) / bw);
v1 = v_scale * (i2fl((v+yd)+hc) / bh);
- glTexCoord2f(u0, v1);
- glVertex2i(x1, y2);
+ glVert[curChar*6 + 0].x = (GLfloat)x1;
+ glVert[curChar*6 + 0].y = (GLfloat)y2;
+ glVert[curChar*6 + 0].u = u0;
+ glVert[curChar*6 + 0].v = v1;
- glTexCoord2f(u1, v1);
- glVertex2i(x2, y2);
+ glVert[curChar*6 + 1].x = (GLfloat)x2;
+ glVert[curChar*6 + 1].y = (GLfloat)y2;
+ glVert[curChar*6 + 1].u = u1;
+ glVert[curChar*6 + 1].v = v1;
- glTexCoord2f(u1, v0);
- glVertex2i(x2, y1);
+ glVert[curChar*6 + 2].x = (GLfloat)x1;
+ glVert[curChar*6 + 2].y = (GLfloat)y1;
+ glVert[curChar*6 + 2].u = u0;
+ glVert[curChar*6 + 2].v = v0;
- glTexCoord2f(u0, v0);
- glVertex2i(x1, y1);
+ glVert[curChar*6 + 3] = glVert[curChar*6 + 1];
+ glVert[curChar*6 + 4] = glVert[curChar*6 + 2];
+
+ glVert[curChar*6 + 5].x = (GLfloat)x2;
+ glVert[curChar*6 + 5].y = (GLfloat)y1;
+ glVert[curChar*6 + 5].u = u1;
+ glVert[curChar*6 + 5].v = v0;
+
+ curChar++;
}
- // done!
- glEnd();
+ glVertexPointer(2, GL_FLOAT, sizeof(struct v4), &glVert[0].x);
+ glTexCoordPointer(2, GL_FLOAT, sizeof(struct v4), &glVert[0].u);
+ glEnableClientState(GL_VERTEX_ARRAY);
+ glEnableClientState(GL_TEXTURE_COORD_ARRAY);
+
+ glDrawArrays(GL_TRIANGLES, 0, curChar * 6);
+
+ glDisableClientState(GL_VERTEX_ARRAY);
+ glDisableClientState(GL_TEXTURE_COORD_ARRAY);
+
GL_state.CullFace(cull_face);
GL_CHECK_FOR_ERRORS("end of string()");
@@ -890,16 +924,21 @@
}
}
+struct v6 { GLfloat x,y,z,w,u,v; };
+struct c4 { GLubyte r,g,b,a; };
+
void opengl_draw_primitive(int nv, vertex **verts, uint flags, float u_scale, float v_scale, int r, int g, int b, int a, int override_primary = 0)
{
GLenum gl_mode = GL_TRIANGLE_FAN;
- float sx, sy, sz, sw, tu, tv;
- int i;
+ float sx, sy, sz, sw;
+ int i,j;
vertex *va;
bool isNebula = false;
bool isRamp = false;
bool isRGB = false;
ubyte alpha = (ubyte)a;
+ struct v6 *vertPos = (struct v6*) alloca(sizeof(struct v6) * nv);
+ struct c4 *vertCol = (struct c4*) alloca(sizeof(struct c4) * nv);
GL_CHECK_FOR_ERRORS("start of draw_primitive()");
@@ -922,12 +961,11 @@
} else if (flags & TMAP_FLAG_QUADLIST) {
gl_mode = GL_QUADS;
} else if (flags & TMAP_FLAG_QUADSTRIP) {
- gl_mode = GL_QUAD_STRIP;
+ gl_mode = GL_TRIANGLE_STRIP;
+ Assert((nv % 2) == 0);
}
- glBegin(gl_mode);
-
- for (i = (nv - 1); i >= 0; i--) {
+ for (i = (nv - 1), j = 0; i >= 0; i--, j++) {
va = verts[i];
sw = 1.0f;
@@ -957,32 +995,67 @@
}
if (override_primary) {
- glColor3ub(va->spec_r, va->spec_g, va->spec_b);
+ vertCol[j].r = va->spec_r;
+ vertCol[j].g = va->spec_g;
+ vertCol[j].b = va->spec_b;
+ vertCol[j].a = 255;
} else {
if (isNebula) {
int pal = (va->b * (NEBULA_COLORS-1)) / 255;
- glColor4ub( gr_palette[pal*3+0], gr_palette[pal*3+1], gr_palette[pal*3+2], alpha );
+ vertCol[j].r = gr_palette[pal*3+0];
+ vertCol[j].g = gr_palette[pal*3+1];
+ vertCol[j].b = gr_palette[pal*3+2];
+ vertCol[j].a = alpha;
} else if (isRamp) {
- glColor4ub( va->b, va->b, va->b, alpha );
+ vertCol[j].r = va->b;
+ vertCol[j].g = va->b;
+ vertCol[j].b = va->b;
+ vertCol[j].a = alpha;
} else if (isRGB) {
- glColor4ub( va->r, va->g, va->b, alpha );
+ vertCol[j].r = va->r;
+ vertCol[j].g = va->g;
+ vertCol[j].b = va->b;
+ vertCol[j].a = alpha;
}
}
if (flags & TMAP_FLAG_TEXTURED) {
- tu = va->texture_position.u * u_scale;
- tv = va->texture_position.v * v_scale;
-
- // use opengl hardware multitexturing
- vglMultiTexCoord2fARB(GL_TEXTURE0_ARB, tu, tv);
- vglMultiTexCoord2fARB(GL_TEXTURE1_ARB, tu, tv);
+ vertPos[j].u = va->texture_position.u * u_scale;
+ vertPos[j].v = va->texture_position.v * v_scale;
}
- glVertex4f(sx, sy, -sz, sw);
+ vertPos[j].x = sx;
+ vertPos[j].y = sy;
+ vertPos[j].z = -sz;
+ vertPos[j].w = sw;
}
- glEnd();
+ glVertexPointer(4, GL_FLOAT, sizeof(struct v6), &vertPos[0].x);
+ glEnableClientState(GL_VERTEX_ARRAY);
+ if(flags & TMAP_FLAG_TEXTURED) {
+ vglClientActiveTextureARB(GL_TEXTURE0);
+ glTexCoordPointer(2, GL_FLOAT, sizeof(struct v6), &vertPos[0].u);
+ glEnableClientState(GL_TEXTURE_COORD_ARRAY);
+
+ vglClientActiveTextureARB(GL_TEXTURE1);
+ glTexCoordPointer(2, GL_FLOAT, sizeof(struct v6), &vertPos[0].u);
+ glEnableClientState(GL_TEXTURE_COORD_ARRAY);
+ }
+
+ if(flags & (TMAP_FLAG_NEBULA | TMAP_FLAG_GOURAUD)) {
+ glColorPointer(4, GL_UNSIGNED_BYTE, 0, &vertCol[0].r);
+ glEnableClientState(GL_COLOR_ARRAY);
+ }
+
+ glDrawArrays(gl_mode, 0, nv);
+
+ glDisableClientState(GL_COLOR_ARRAY);
+ glDisableClientState(GL_VERTEX_ARRAY);
+ glDisableClientState(GL_TEXTURE_COORD_ARRAY);
+ vglClientActiveTextureARB(GL_TEXTURE0);
+ glDisableClientState(GL_TEXTURE_COORD_ARRAY);
+
GL_CHECK_FOR_ERRORS("start of draw_primitive()");
}
@@ -1726,19 +1799,7 @@
glColor4f(1.0f, 1.0f, 1.0f, gr_screen.current_alpha);
- glBegin(GL_QUADS);
- glTexCoord2f(u0, v1);
- glVertex2f(x1, y2);
-
- glTexCoord2f(u1, v1);
- glVertex2f(x2, y2);
-
- glTexCoord2f(u1, v0);
- glVertex2f(x2, y1);
-
- glTexCoord2f(u0, v0);
- glVertex2f(x1, y1);
- glEnd();
+ opengl_draw_textured_quad(x1, y1, u0, v0, x2, y2, u1, v1);
}
Index: graphics/gropengldraw.h
===================================================================
--- graphics/gropengldraw.h (revision 8833)
+++ graphics/gropengldraw.h (working copy)
@@ -47,6 +47,10 @@
void gr_opengl_scene_texture_begin();
void gr_opengl_scene_texture_end();
+inline void opengl_draw_textured_quad(
+ GLfloat x1, GLfloat y1, GLfloat u1, GLfloat v1,
+ GLfloat x2, GLfloat y2, GLfloat u2, GLfloat v2 );
+
extern int Scene_texture_initialized;
extern GLuint Scene_color_texture;
Index: graphics/gropenglpostprocessing.cpp
===================================================================
--- graphics/gropenglpostprocessing.cpp (revision 8833)
+++ graphics/gropenglpostprocessing.cpp (working copy)
@@ -155,20 +155,8 @@
GL_state.Texture.SetTarget(GL_TEXTURE_2D);
GL_state.Texture.Enable(Scene_color_texture);
- glBegin(GL_QUADS);
- glTexCoord2f(0.0f, 0.0f);
- glVertex2f(-1.0f, -1.0f);
+ opengl_draw_textured_quad(-1.0f, -1.0f, 0.0f, 0.0f, 1.0f, 1.0f, 1.0f, 1.0f);
- glTexCoord2f(1.0f, 0.0f);
- glVertex2f(1.0f, -1.0f);
-
- glTexCoord2f(1.0f, 1.0f);
- glVertex2f(1.0f, 1.0f);
-
- glTexCoord2f(0.0f, 1.0f);
- glVertex2f(-1.0f, 1.0f);
- glEnd();
-
GL_state.Texture.Disable();
// ------ end bright pass ------
@@ -200,19 +188,7 @@
GL_state.Texture.Enable(Post_bloom_texture_id[pass]);
- glBegin(GL_QUADS);
- glTexCoord2f(0.0f, 0.0f);
- glVertex2f(-1.0f, -1.0f);
-
- glTexCoord2f(1.0f, 0.0f);
- glVertex2f(1.0f, -1.0f);
-
- glTexCoord2f(1.0f, 1.0f);
- glVertex2f(1.0f, 1.0f);
-
- glTexCoord2f(0.0f, 1.0f);
- glVertex2f(-1.0f, 1.0f);
- glEnd();
+ opengl_draw_textured_quad(-1.0f, -1.0f, 0.0f, 0.0f, 1.0f, 1.0f, 1.0f, 1.0f);
}
GL_state.Texture.Disable();
@@ -323,20 +299,8 @@
GL_state.Texture.SetTarget(GL_TEXTURE_2D);
GL_state.Texture.Enable(Scene_color_texture);
- glBegin(GL_QUADS);
- glTexCoord2f(0.0f, 0.0f);
- glVertex2f(-1.0f, -1.0f);
+ opengl_draw_textured_quad(-1.0f, -1.0f, 0.0f, 0.0f, 1.0f, 1.0f, Scene_texture_u_scale, Scene_texture_u_scale);
- glTexCoord2f(Scene_texture_u_scale, 0.0f);
- glVertex2f(1.0f, -1.0f);
-
- glTexCoord2f(Scene_texture_u_scale, Scene_texture_v_scale);
- glVertex2f(1.0f, 1.0f);
-
- glTexCoord2f(0.0f, Scene_texture_v_scale);
- glVertex2f(-1.0f, 1.0f);
- glEnd();
-
GL_state.Texture.Disable();
// set and configure post shader ..
@@ -353,20 +317,8 @@
GL_state.Texture.SetTarget(GL_TEXTURE_2D);
GL_state.Texture.Enable(Scene_luminance_texture);
- glBegin(GL_QUADS);
- glTexCoord2f(0.0f, 0.0f);
- glVertex2f(-1.0f, -1.0f);
+ opengl_draw_textured_quad(-1.0f, -1.0f, 0.0f, 0.0f, 1.0f, 1.0f, Scene_texture_u_scale, Scene_texture_u_scale);
- glTexCoord2f(Scene_texture_u_scale, 0.0f);
- glVertex2f(1.0f, -1.0f);
-
- glTexCoord2f(Scene_texture_u_scale, Scene_texture_v_scale);
- glVertex2f(1.0f, 1.0f);
-
- glTexCoord2f(0.0f, Scene_texture_v_scale);
- glVertex2f(-1.0f, 1.0f);
- glEnd();
-
GL_state.Texture.Disable();
opengl_shader_set_current();
@@ -432,19 +384,9 @@
glColor4f(1.0f, 1.0f, 1.0f, 1.0f);
GL_state.Blend(GL_TRUE);
GL_state.SetAlphaBlendMode(ALPHA_BLEND_ADDITIVE);
- glBegin(GL_QUADS);
- glTexCoord2f(0.0f, 0.0f);
- glVertex2f(-1.0f, -1.0f);
+
+ opengl_draw_textured_quad(-1.0f, -1.0f, 0.0f, 0.0f, 1.0f, 1.0f, Scene_texture_u_scale, Scene_texture_u_scale);
- glTexCoord2f(Scene_texture_u_scale, 0.0f);
- glVertex2f(1.0f, -1.0f);
-
- glTexCoord2f(Scene_texture_u_scale, Scene_texture_v_scale);
- glVertex2f(1.0f, 1.0f);
-
- glTexCoord2f(0.0f, Scene_texture_v_scale);
- glVertex2f(-1.0f, 1.0f);
- glEnd();
GL_state.Blend(GL_FALSE);
break;
}
@@ -511,20 +453,7 @@
GL_state.Texture.SetTarget(GL_TEXTURE_2D);
GL_state.Texture.Enable(Scene_color_texture);
- glBegin(GL_QUADS);
- glTexCoord2f(0.0f, 0.0f);
- glVertex2f(-1.0f, -1.0f);
-
- glTexCoord2f(Scene_texture_u_scale, 0.0f);
- glVertex2f(1.0f, -1.0f);
-
- glTexCoord2f(Scene_texture_u_scale, Scene_texture_v_scale);
- glVertex2f(1.0f, 1.0f);
-
- glTexCoord2f(0.0f, Scene_texture_v_scale);
- glVertex2f(-1.0f, 1.0f);
- glEnd();
-
+ opengl_draw_textured_quad(-1.0f, -1.0f, 0.0f, 0.0f, 1.0f, 1.0f, Scene_texture_u_scale, Scene_texture_u_scale);
// Done!
GL_state.Texture.SetActiveUnit(1);
-
...it gets over the ****ing von neuman bottleneck for example.
I don't see how, unless you mean the caches that every CPU since the 68030 has had to some extent. The RAM is often very close to the CPU these days (and the R-Pi uses package-on-package to maximise that), but the bottleneck still exists.
The nearest thing to a solution I've yet seen is the layout of a modern high-end graphics card, which uses many narrow RAM channels in parallel, gives each of them a separate L2 cache, and pipelines the shader engines so insanely deeply that the latency can be completely hidden in many cases. But it's still possible to run even one of those monsters in a RAM bandwidth starved mode.
in that memory and instruction memories are kept separate, if im reading the arm1176JZF-S technical reference manual (http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/DDI0301H_arm1176jzfs_r0p7_trm.pdf) (from the raspberry pi wiki) correctly. at least in the level one memory system (section 7 in the manual), though im not sure about the level 2 memory system. it states that "separate Instruction and Data Caches in a Harvard arrangement", referencing harvard architecture model, which was developed in response to the von neuman bottleneck. of course im making a lot of assumptions base on a 10 minute scan through of a manual which would probibly take a week or two to read and comprehend.
-
Ah, I see. ARM uses a unified memory space like most CPUs, and for quite a while also a Harvard-type L1 cache - also like most modern CPUs. This is a standard feature these days (eg. Pentium and anything newer) because it allows instruction prefetch to proceed largely independent of data accesses, without needing to dual-port the cache memory cells.
Note that some older ARM CPUs, such as the ARM6 and ARM7 cores, used a small unified L1 cache. This utterly failed to matter because the cache could refill the instruction prefetch buffer after servicing a data access. Most likely the cache was also dual-ported so that concurrent hit accesses were also possible.
But the memory bottleneck still exists for datasets that exceed the cache size, so the von Neumann problem is still there.
However, the ratio between the R-Pi's CPU core and it's memory is unusually shallow - it is an old core (700MHz, single issue) coupled to a relatively fast memory (400MHz DDR2, forget whether it's 32 or 64 bits wide). Yet the bottleneck can still be there even in this case, because the RAM bandwidth is shared with a rather powerful GPU, which is more latency tolerant but hungrier for bandwidth than the CPU (when it is in use).
-
i didnt know about that, i guess you learn something new every day. modern cpus have a lot of complex details about them, where as a cpu from the 80s (or one in a modern microcontroller such as avr) is an amazingly simple little device compared to behemoths like modern x86 and arm cpus.
-
My R-Pi arrived, and I spent a good deal of the weekend figuring out which of my large collection of SD cards worked well in it. It looks like the great majority of them are at least functional, but for the moment I'm setting up Gentoo mainly on an 8GB USB drive, so the SD card only holds boot components and a swap partition. As should be expected, compiling stuff takes a while, but the FPU seems to be relatively competent which will definitely help.
So far the power meter I inserted under the PSU is consistently reading under 4 watts at the wall. That's including the USB flash drive, but I haven't really exercised the 3D engine yet.
Once Gentoo is working properly, I should be able to explore what precisely I can do with the 3D accelerator and under what circumstances the sound output works. The sound unfortunately doesn't seem to be a standard ALSA or OSS device, which might need to be corrected sharpish if OpenAL is going to work. One thing is clear: we are independent of X11 for 3D work.
I also have two other ARM boxes which at least nominally support OpenGL ES 2, but the R-Pi is my primary target. If it runs there, it should run quite easily on the others too.
-
My R-Pi arrived, and I spent a good deal of the weekend figuring out which of my large collection of SD cards worked well in it. It looks like the great majority of them are at least functional, but for the moment I'm setting up Gentoo mainly on an 8GB USB drive, so the SD card only holds boot components and a swap partition. As should be expected, compiling stuff takes a while, but the FPU seems to be relatively competent which will definitely help.
cross-compiling might work here?
One thing is clear: we are independent of X11 for 3D work.
Oh? and how do you expect to make it run FSO then?
(not trying to sound condescending, but my experience with linux in that area is sketchy at best, so i'd like some clarification, if possible)
-
thats one of the advantages to using a compiler. a majority of the code is basic math and logic, which should work right of the bat. some of it api interfaces, which likely use the same interfaces as the x86 linux builds and therefore is covered. i figure most of the work, aside from substitutions for libraries that dont work on arm, will be finding areas of code which can be optimized for arm architecture, and address those until the game engine is stable and runs with decent performance. its not something id attempt, im not that good of a programmer.
-
Recieved an email from farnell yesterday, mine has been shipped.
-
There will be a few things that need to be changed, the biggest amount of work being (as previously mentioned) replacing all the GL calls that were obsolete 10 years ago and therefore don't exist in OpenGL ES, and updating the rest so that they all use shaders by default. All without breaking compatibility with old desktop cards that don't support shaders at all.
Normal FSO opens an X11 window as part of obtaining a GL context to render to. The 3D stuff on the R-Pi doesn't work that way - you get a framebuffer surface from somewhere else, and then obtain a GLES context on that using EGL. At least one of the other machines will require an X11 window to pass to EGL as "normal". The practical upshot is that on the R-Pi you will be starting FSO from the text console, without an X11 server hogging half the RAM and VRAM before you've even started to load models and textures. This affects only a very small bit of code related to game startup.
The sound being non-standard is a concern, but if need be I can plug in an external USB soundcard which will be visible to ALSA and thence OpenAL in the normal way. Linux is sufficiently flexible that way. If I need to do that, I can raise hell with some people to get the internal sound wired up properly, which will help all the other R-Pi users (approaching 100k now, I think).
Compiling is slow mostly, I think, because the ARM11 core only decodes and issues one instruction per cycle. Most modern CPUs deal with two or three instructions per cycle if the stars are aligned right, and they have corresponding numbers of ALUs to absorb that flow. For floating-point-heavy stuff (ie. most of the heavy work when running a game) this doesn't matter so much because there is usually only one FPU pipeline, so as long as the FPU and GPU are competent - and I think they are - we should get good game performance.
-
I was about to suggest to just forget about R-PI and its ARM11 cpu and think about AllWinner A10 cpu board, those things just kicked out VIA 8650 as a cheap solution, there is a huge number of cheap tablets running these, and a lot of TVBox are coming, it comes with a minimum of 512MB ram, its ARMv7 (A8) 1 to 1.5ghz, Mali-400 gpu (a bit weaker than R-PI one), native SATA and a 2160P/3D high bitrate and multi format video decoder, not important for FS2(maybe for cutscenes), but is a great indication that those things will be invading TVBox market soon.
And one mayor point is, A10 load u-boot from external SDCard as Primary Boot, so basicly you insert a SDcard loaded with a Linux in ANY A10 device and thats it, its running Linux in less than 30seconds....
This is when i tested it in my Novo 7 Aurora tablet -> http://i.imgur.com/ovTLH.png its as easy as it sounds. and these of another user http://i.imgur.com/6pH5a.jpg
Devices with A10 are a bit expensive than R-PI, there is the Mele A1000 and MK802 TVBoxes.
BUT X11 lacks GPU hardware/OpenGL ES support at this moment(as well the video decoder), but its coming, as well XBMC. But its something to have in consideration... R-PI is not the only choice.
http://www.j1nx.nl/multimedia/openelec-xbmc-mele-a1000-update/
-
If it runs on R-Pi, it'll run quite easily on almost anything else. Also, I actually have one now. That's why I'm using it as a target.
-
Last night i was VERY BORED and i was playing with Lubuntu on my A10 tablet testing Java SE Embedded, etc, and i decided to compile FSO on it just for the fun of it, but THIS was unexpected...
(http://i.imgur.com/CYi18.jpg)
Why is even working? I still dont have X11 running on the Mali gpu, and even if was, its OpenGL ES, there is a full opengl running on software there, somehow.
-
^^thats pretty impressive.
hey how much did you all have to pay shipping on your pis (to us)? i got the money for mine, though it seems i have to sit on a waiting list for some time before im even allowed to attempt ordering anything.
-
Shivansps, ever heard of the mesa drivers?
-
Yes indeed, you're looking at the Mesa software rasteriser there. It's not fast by any stretch of the imagination, it's just there so that OpenGL apps (generally *not* games) will always work.
Try running glxinfo | less.
-
hey how much did you all have to pay shipping on your pis (to us)? i got the money for mine, though it seems i have to sit on a waiting list for some time before im even allowed to attempt ordering anything.
UK-based here, but Farnell (CPC, Element14) were offering their price inclusive of shipping when I registered on launch day, turned out to be £30 inc VAT & P&P.
Was able to order back in May, and it's finally en-route to me as I post this!
They are starting to catch up with demand, it'll take a while though - IIRC the original batch was 10,000 but they had orders for 100,000 in the first few hours.
The manufacturing ramp-up has been quite extraordinary.
(Can't help but think somebody high-up at Broadcom owes Eben and co one heck of a bar bill.)
-
Yeah its there...
miniand@miniand:/lib$ dpkg --get-selections | grep mesa
libegl1-mesa install
libegl1-mesa-drivers install
libgl1-mesa-dev install
libgl1-mesa-dri install
libgl1-mesa-glx install
libglapi-mesa install
libgles2-mesa install
libglu1-mesa install
libglu1-mesa-dev install
libopenvg1-mesa install
mesa-common-dev install
It should have come with libbsd-dev.
Thats what it says glxinfo too after ive installed the mesa-tools...
Im suprised it can even hit 4fps with a software renderer on something weak as a Cortex A8... i think A10 processors will have no problems running FS2 at all, and R-PI has a much better GPU.
BTW, what about the insane number of "deprecated conversion from string constant to 'char*'" while compiling?
-
I got the impression that 4fps is as low as the FSO frame counter will read - so probably you aren't really getting that much. At those levels you should be able to count frames manually, though. It's sensible to have a limit somewhere in that region, so that overloading your machine doesn't permanently lock up your game.
I have another game which puts the low limit as high as 14fps. Below that framerate it does not run in realtime. This is rather problematic for a train simulator, where low fps is tolerable (train controls take a second or so to respond anyway) but running at variable speeds is not (due to judging braking distances to stop accurately in platforms). This is not helped by the inefficient rendering engine (I think it might actually be *worse* than stock FSO if you can believe it) and the increasingly detailed objects and scenery involved. Framerates are usually similar to Crysis on the same hardware, and without the quality.
-
BTW, what about the insane number of "deprecated conversion from string constant to 'char*'" while compiling?
See here (http://www.hard-light.net/forums/index.php?topic=80961.msg1611626#msg1611626), but basically, you can ignore them. The SCP is working on ensuring that they don't appear in the future.
-
It starts at 2fps and them moves to 4fps and it gets stuck there, so you may be right.
Is such a shame that something with potent gpu, like R-PI to have a ARM11 cpu... with that gpu it may even display full mediavps at 1080P, i dont think that Mali-400 will be able to handle anything more than stock vps...
But well, we'll see once its done.
And as long i have this tablet i can run FS2 tests on his ARMv7 cpu once we get the code update :P
EDIT: jg18:
Thanks, i see, i trought it was the ARM compiler giving trouble.
-
Well, I did find that the Pentium-3 laptop I tried was very much limited by it's GPU - a Rage128. Actually, it seemed to be mostly limited by the relative lack of VRAM for the textures. This is with retail binaries and data - the Rage128 drivers for WinXP didn't seem to support OpenGL, so I couldn't run FSO at all.
The ARM11's FPU is relatively powerful compared to the rest of the CPU - it can be used very much like a Cray-1, firing off vectors of operations to complete in sequence and in parallel - and seems to be on par with the Pentium 3 at the same clock speed (assuming an ordinary compiler rather than hand optimisation). Indeed, if the compiler doesn't use the SSE versions of the FP instructions, the P3 gets a significant penalty to multiply and add throughputs because x87 instructions always run at extended precision. The ARM11 can pipeline independent single-precision multiply-adds at one per cycle, which is on par with many relatively modern CPUs (Bulldozer and PPC970 can do better without SIMD, Sandy Bridge can't). It seems that ARM decided that if you were bothering to fit an FPU, you probably really needed it!
The ARM11 is also more closely coupled to the memory than a Pentium-3. Remember that in those days, Intel still attached the memory via the separate Northbridge chip, which introduced a lot of latency compared to an on-die memory controller as used today. The Northbridge in the laptop is the ubiquitous i440BX, which has fairly poor latency. The ARM11 has to share memory access with the GPU, but the latency should still generally be lower than a northbridge design would be.
So the main handicaps that the ARM11 has compared to the P3 is the decode/issue bandwidth of one instruction per cycle, versus up to three for Intel, and the lack of wide SIMD support. It remains to be seen how important that is in practice - I suspect it really isn't very important.
-
But i trought it where GPU limited because of using old OpenGL code. Fixing GPU programing will likely cause CPU usage to increase, overall it will be always better, but im sure that will be CPU limited on R-PI, and memory... well, i dont know if the amount of shared ram will be enoght for mediavps...
Im angry about it because this is something ive be telling in the R-PI forum since i found out about that thing, 128/256mb was a poor choice of ram, ARM11 a bad choice for cpu also its video decode is not good enoght to be a good choice for HTPC, they say its for "programing" ARM11 for programing, yeah ok, with those compiling times...
But anyway, if its slow, i can always test on a A10, Mali-400 will be the bottleneck here for sure :P But with 1GB of ram, there is a nice margin to play with, even with X11 running, even wxlauncher works ok.
-
Im angry about it because this is something ive be telling in the R-PI forum since i found out about that thing, 128/256mb was a poor choice of ram, ARM11 a bad choice for cpu also its video decode is not good enoght to be a good choice for HTPC, they say its for "programing" ARM11 for programing, yeah ok, with those compiling times...
And what, in your infinite wisdom, would have been a better choice, given the R-Pi budget constraints?
-
The next bcm processor that is ARMv7 and minimum 512mb ram, 10 bucks more or less is still cheap. (as BCM its the only choice for them)
Have you see the number of people complaining about the lack of instruccion sets? compiling times, or that the XBMC UI is slow? even using hardware GLES.
Its cheap, but it was too late and too little, its powerfull gpu is its only streght, but its like having a HD7950 with a Pentium 3 and 200mb of ram... GPGPU is the only good thing that it may come out of it, and R-PI gpu does not support it because its not using programable shaders, and its code locked too...
Im not saying is too bad, it is a good iniciative, but it seems like a wasted opportunity. I hope they step up cpu and ram in the next model...
-
Again, please provide proof that that hardware was available for the price necessary at the time the R-Pi project got started. I have no doubt that the next version of the Pi will be an upgrade, but please bear in mind the constraints the original hardware was released under; the price point was one of the hard constraints that the makers didn't want to violate, as far as I know. *****ing about how it could be better if it were more expensive is missing the point by quite a margin.
But i trought it where GPU limited because of using old OpenGL code. Fixing GPU programing will likely cause CPU usage to increase,
The exact opposite is true. FSO is CPU-limited because the graphics code does far too many things on the CPU side of things; Fixing our OpenGL pipeline is largely about using fewer OpenGL commands and state switches to achieve the same goal.
-
the pi is about $20 cheaper than my first arduino and about 35x faster (forgetting the fact that its 8-bit vs 32-bit), not to mention it has an fpu and gpu while an arduino does not. even if it doesnt pan out in the running freespace department im sure i can use it for my other freespace related ideas (http://www.hard-light.net/forums/index.php?topic=80737.0). not to mention many a hardware project thanks to its gpio capabilities.
-
The retail code I ran on the old laptop doesn't use OpenGL at all - it is Direct3D. I have no idea whether that implementation is efficient or not, but it runs well on old hardware so it can't be too awful.
The R-Pi's GPU *does* support programmable shaders, via OpenGL ES 2. But to use that, we have to thoroughly overhaul the rendering engine as described at length previously. Hopefully this overhaul will allow using the GPU more thoroughly and involving the CPU less. An intermediate goal will be to use OpenGL ES 1, which requires vertex arrays but doesn't support shaders - this is more similar to the way the bulk of the current code works.
The relatively small amount of VRAM (128MB at maximum, if half the RAM is dedicated to it) is likely to limit the number of advanced features we can turn on. But my experience with a 16MB Rage128 Mobility suggests that retail data plus glow/shine maps plus hi-poly models shouldn't be a problem. Beyond that we'll just have to see. The Foundation has stated clearly that increasing total RAM to 512MB would have been considerably more expensive, out of proportion to the increase in capacity - but they did manage to find 256MB chips cheap enough to fit to the Model A as well as the Model B. Originally they had planned to fit only 128MB total to the Model A.
And, as I just mentioned, the ARM11 isn't as weak as you might assume if you are used to this year's desktop PCs. It is much less capable than Sandy Bridge or even Tegra 3, but it is significantly more powerful than the minimum requirements for retail FS2, especially in the FPU and memory access departments which matter most. It will be worth coding efficiently, that is all.
-
Well, we are trying. Next thing on my list of things to do would be to update the patch I posted previously in this thread (and which was largely ignored :( ) to work well with the changes introduced recently (we moved glowpoint rendering to use the batch renderer instead of rendering them during model rendering).
Oh, and there are a few things Valathil is working on which may also offer benefits in the future. See: http://www.youtube.com/watch?v=LXDXQMSmXe4&feature=g-all-u and http://www.youtube.com/watch?v=q4Z2s3Q8t5E&feature=g-all-u
-
Yes, that sort of patch looks to be very helpful when I finally get around to restarting work on this. I didn't ignore it, but I wasn't quite ready to make use of it since I was in the final stages of an important project at work.
How much work would the update to the latest trunk require?
-
Not much, I believe. Should be doable in a couple minutes, tops (I just couldn't do it while away from my home comp)
EDIT: Aaaand committed in revision 8973
-
Good - I'll look forward to it then. :nod:
-
My R-Pi is currently a bit overloaded with compiling Firefox (one of the link stages is using 900MB, so is mostly in swap), but I was able to checkout that revision (after first compiling subversion) and have a look.
There are still 15 calls to glBegin in gropengldraw.cpp, but this seems to be a much smaller overall number than I remember. Good work. We need to remove *all* such calls no matter how little they are used, and probably take care of a few other compatibility quirks, before OpenGL ES 1 will work. That's in addition to modifying the context creation logic (which will have to be hidden behind a configure flag).
First however, I'm going to build it for straight OpenGL/GLX and try to run it with the display on one of my Linux desktops. X11 is helpful that way, even if it's nasty in a lot of other ways. The 100Mbps network link will probably be the bottleneck, but this should at least tell us something concrete about the CPU usage, since people seem to be worried about that.
-
oh i was to post this earlier and i forget, this is the list of dependencys to build fso and wxlauncher, i did not find the list of dependencys anywhere, i know configure tell you what ones are missing, but its kind of a waste of time.
autoconf subversion build-essential libsdl1.2-dev liblua5.1-dev libtheora-dev libvorbis-dev libogg-dev libjpeg-dev libopenal-dev cmake mercurial libwxgtk2.8-dev python-markdownThe last 4 are for wxlauncher only.
When i compiled fso on my A10 it took about 45mins, i wonder if CC is possible.
I was missing fred2, i think there is a argument for that.
What i was trying to compile out of curiosity is "glesport", is some kind of a modified old mesa gl lib that act as a wrapper that intercept gl calls and convert them to gles, i can imagine the process to be very slow, but still better than using the software renderer, i heard of some people that managed to run Quake 2 with that...
-
AFAIK you won't get FRED on Linux, it has too many Windows specific things.
I think I have most of the dependencies already, but I'l just build the ones I don't have yet. I'm using Gentoo...
-
the pi is about $20 cheaper than my first arduino and about 35x faster (forgetting the fact that its 8-bit vs 32-bit), not to mention it has an fpu and gpu while an arduino does not. even if it doesnt pan out in the running freespace department im sure i can use it for my other freespace related ideas (http://www.hard-light.net/forums/index.php?topic=80737.0). not to mention many a hardware project thanks to its gpio capabilities.
I just checked the prices, the R-PI B is about 50-55 usd with shipping with unknow avalibility.
I quick search on ebay i get (im not going to post links): With the AllWinner A10 processor
-100usd for Mele A1000 TVBox (512MB ram, with all video outputs, ethernet and a real SATA port)
-90usd for Mini X (1gb ram, remote control)
-75usd for MK802 (1gb ram)
All free shipping, every one of them comes with a case, DC adapter, some even HDMI cable, Wifi N, 4GB internal flash, dual boot Android 4.0.3 and Linux(and soon XBMC), very high bitrate multi-format 2160P VPU(with 3D support somehow), and a 1 to 1.5ghz ARMv7 cpu, so yeah, R-PI is cheaper and have a better gpu (Mali-400 on A10), but if i going to have something to use as a HTPC with capability to play FSO its not going to be the R-PI, also there is a lot of cheap A10 tablets out there.
It depends on what use every one of us want to give them.
-
oh i was to post this earlier and i forget, this is the list of dependencys to build fso and wxlauncher, i did not find the list of dependencys anywhere, i know configure tell you what ones are missing, but its kind of a waste of time.
The wiki has a dependencies list for different distros: http://www.hard-light.net/wiki/index.php/Fs2_open_on_Linux/Installing_the_Development_Libraries
And here's the start of the "Linux guide": http://www.hard-light.net/wiki/index.php/Guide_to_FS_Open_on_Linux
-
oh i was to post this earlier and i forget, this is the list of dependencys to build fso and wxlauncher, i did not find the list of dependencys anywhere, i know configure tell you what ones are missing, but its kind of a waste of time.
The wiki has a dependencies list for different distros: http://www.hard-light.net/wiki/index.php/Fs2_open_on_Linux/Installing_the_Development_Libraries
And here's the start of the "Linux guide": http://www.hard-light.net/wiki/index.php/Guide_to_FS_Open_on_Linux
oh i did not look in the wiki, sorry.
Anyway, with config is not hard to figure it out either, but it seem odd there where no a "how to build" file on the svn, or maybe its there and dindt see it... i think there should be a link to that wiki page in the readme/install files in the svn.
-
good point - I'll have to have a look at that, I know many of the README/CHANGE/INSTALL (& similar) files in the project are out of date...
-
the pi is about $20 cheaper than my first arduino and about 35x faster (forgetting the fact that its 8-bit vs 32-bit), not to mention it has an fpu and gpu while an arduino does not. even if it doesnt pan out in the running freespace department im sure i can use it for my other freespace related ideas (http://www.hard-light.net/forums/index.php?topic=80737.0). not to mention many a hardware project thanks to its gpio capabilities.
I just checked the prices, the R-PI B is about 50-55 usd with shipping with unknow avalibility.
if its more than $50 il just have to wait another month or two. there are other arm platforms i guess but the thing is i want the pi because it is better suited for the uses i have in mind. also i plan to get me a 3d printer or laser cutter in a few months with which an appropriate enclosure could be fabricated.
-
EDIT: Aaaand committed in revision 8973
The E - I think you need to declare inline functions in the header, not the .cpp? Otherwise you get this when compiling with gcc:
libcode.a(gropenglpostprocessing.o): In function `opengl_post_pass_fxaa()':
gropenglpostprocessing.cpp:(.text+0x216f): undefined reference to `opengl_draw_textured_quad(float, float, float, float, float, float, float, float)'
gropenglpostprocessing.cpp:(.text+0x2219): undefined reference to `opengl_draw_textured_quad(float, float, float, float, float, float, float, float)'
libcode.a(gropenglpostprocessing.o): In function `gr_opengl_post_process_end()':
gropenglpostprocessing.cpp:(.text+0x24b4): undefined reference to `opengl_draw_textured_quad(float, float, float, float, float, float, float, float)'
gropenglpostprocessing.cpp:(.text+0x25a7): undefined reference to `opengl_draw_textured_quad(float, float, float, float, float, float, float, float)'
gropenglpostprocessing.cpp:(.text+0x2651): undefined reference to `opengl_draw_textured_quad(float, float, float, float, float, float, float, float)'
libcode.a(gropenglpostprocessing.o):gropenglpostprocessing.cpp:(.text+0x28ae): more undefined references to `opengl_draw_textured_quad(float, float, float, float, float, float, float, float)' follow
collect2: ld returned 1 exit status
make[1]: *** [fs2_open_INF_r] Error 1
make: *** [all-recursive] Error 1
Here's a potential patch:
Index: fs2_open/code/graphics/gropengldraw.cpp
===================================================================
--- fs2_open/code/graphics/gropengldraw.cpp (revision 8978)
+++ fs2_open/code/graphics/gropengldraw.cpp (working copy)
@@ -59,29 +59,6 @@ void gr_opengl_pixel(int x, int y, bool resize)
gr_line(x, y, x, y, resize);
}
-inline void opengl_draw_textured_quad(
- GLfloat x1, GLfloat y1, GLfloat u1, GLfloat v1,
- GLfloat x2, GLfloat y2, GLfloat u2, GLfloat v2 )
-{
- GLfloat glVertices[4][4] = {
- { x1, y1, u1, v1 },
- { x1, y2, u1, v2 },
- { x2, y1, u2, v1 },
- { x2, y2, u2, v2 }
- };
-
- glVertexPointer(2, GL_FLOAT, sizeof(glVertices[0]), glVertices);
- glTexCoordPointer(2, GL_FLOAT, sizeof(glVertices[0]), &(glVertices[0][2]));
-
- glEnableClientState(GL_VERTEX_ARRAY);
- glEnableClientState(GL_TEXTURE_COORD_ARRAY);
-
- glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
-
- glDisableClientState(GL_VERTEX_ARRAY);
- glDisableClientState(GL_TEXTURE_COORD_ARRAY);
-}
-
void opengl_aabitmap_ex_internal(int x, int y, int w, int h, int sx, int sy, bool resize, bool mirror)
{
if ( (w < 1) || (h < 1) ) {
Index: fs2_open/code/graphics/gropengldraw.h
===================================================================
--- fs2_open/code/graphics/gropengldraw.h (revision 8978)
+++ fs2_open/code/graphics/gropengldraw.h (working copy)
@@ -49,7 +49,26 @@ void gr_opengl_scene_texture_end();
inline void opengl_draw_textured_quad(
GLfloat x1, GLfloat y1, GLfloat u1, GLfloat v1,
- GLfloat x2, GLfloat y2, GLfloat u2, GLfloat v2 );
+ GLfloat x2, GLfloat y2, GLfloat u2, GLfloat v2 )
+{
+ GLfloat glVertices[4][4] = {
+ { x1, y1, u1, v1 },
+ { x1, y2, u1, v2 },
+ { x2, y1, u2, v1 },
+ { x2, y2, u2, v2 }
+ };
+
+ glVertexPointer(2, GL_FLOAT, sizeof(glVertices[0]), glVertices);
+ glTexCoordPointer(2, GL_FLOAT, sizeof(glVertices[0]), &(glVertices[0][2]));
+
+ glEnableClientState(GL_VERTEX_ARRAY);
+ glEnableClientState(GL_TEXTURE_COORD_ARRAY);
+
+ glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
+
+ glDisableClientState(GL_VERTEX_ARRAY);
+ glDisableClientState(GL_TEXTURE_COORD_ARRAY);
+}
extern int Scene_texture_initialized;
also i plan to get me a 3d printer or laser cutter in a few months with which an appropriate enclosure could be fabricated.
You could try a lego case? :nervous:
(http://mikos.co.uk/2012-06-24-11.34.jpg)
-
also i plan to get me a 3d printer or laser cutter in a few months with which an appropriate enclosure could be fabricated.
You could try a lego case? :nervous:
(http://mikos.co.uk/2012-06-24-11.34.jpg)
actually that was my interim plan, i got more legos than i know what to do with. one of the things i intend to use my future 3d printer for is custom bricks, and do away with destructive brick modding techniques.
-
The E - I think you need to declare inline functions in the header, not the .cpp? Otherwise you get this when compiling with gcc:
I think gcc needs to be less stupid, but what do I know?
-
The E - I think you need to declare inline functions in the header, not the .cpp? Otherwise you get this when compiling with gcc:
I think gcc needs to be less stupid, but what do I know?
Clang/LLVM also agrees with GCC on this one. Committing fix to trunk.
-
On general principle, inline functions need to have their implementation visible at point of calling. I'm glad people found a use for that one in more than one file.
-
I just tried to run FSO with the CPU end on my R-Pi and the graphics end on a spare PC that has a Radeon X1650 Pro. It didn't work as well as I was hoping - but that was because it refused to forward the GL commands over the network as I was hoping, but instead rendered it all in software and then pushed the completed frames over the network. As you can imagine, this was unusably slow.
This isn't the R-Pi's fault. I got exactly the same results (and similar performance) when trying to forward FSO from my nettop. This is despite the nettop having an allegedly better CPU (well, Atom, so arguable either way) and a much faster Ethernet chipset.
So I think I'd better get on with actually porting this stuff to run natively. I was hoping to get an idea of the CPU load first, but oh well.
-
yup, i think you where creating your own "Virtu" over there :P
Oh, and ALSA Sound works perfectly on HDMI with A10, Alsa support is embedded on the kernel for A10 last time i checked when i builded one.
Now that i got my Linaro armhf build ready, im trying to get OpenGL ES to work on Mali, it should be possible as long the game use the framebuffer directly, as X11 dont like Mali very much for wharever reason -.-
-
BTW, as of revision 8998 (It's UNDER 9000!!) all the rest of the glBegin()/glEnd() pairs have been removed.
-
I wonder if is posible to use Theorarm instead of Theora for ARM builds? I think it will be the only way to make those .ogg vids to play OK on almost any ARM cpu...
-
Most OpenGL ES implementations aren't integrated properly with X11. I think the possibility of having to deal with a partially occluded window and more than one context active at a time gives them hives. The obvious exceptions are GLES implementations that are just reconfigurations of full desktop GL implementations.
Personally I'm not using the Theora movies, but the original MVEs. They look better and are much less CPU intensive to decode. Only problem is they take more disk space. However, if you install Theorarm I don't see why it wouldn't be possible to link FSO to it.
-
Oh and excellent news about Begin/End pairs. Now we can start on the other things that are not supported by GLES, such as QUADS and QUAD_STRIP. I think that is the main thing likely to lead to a compile failure against ES1.
QUAD_STRIP is not much of a problem. As long as the number of vertices is even (which it should be anyway), identical behaviour will be produced by TRIANGLE_STRIP. If the number is odd, TRIANGLE_STRIP will add a spurious triangle on the end, but that would be a problem in the vertex data so I hope it isn't there. It should be easy to implement, anyway.
QUADS is trickier. Each QUAD can be replaced by two triangles, either in TRIANGLE_STRIP or TRIANGLES mode, but the vertex order required is different in each case, and 50% more vertices are required (repeating the first and last vertex for TRIANGLE_STRIP to flush the vertex buffer between quads, or repeating the middle pair in TRIANGLES to butt one half against the other). I suggest using TRIANGLES because it means less work for the GPU, since it doesn't have to delete the degenerate triangles.
As an aside, POINTS is always implemented by point-sprites on GLES. This may or may not matter, we'll see. Possibly, many previously valid uses of QUADS can be replaced by point-sprites - I'm thinking of the radar here.
In a couple of places, the polygon mode is set by external data. In these cases, a stopgap solution might be to dump a warning to the console when QUADS is used, and then just render with TRIANGLE_STRIP for now. This should produce halfway sane but obvious rendering artefacts to tell us that it needs to be fixed properly. We can also breakpoint on the console print call to figure out where the request is coming from.
The other major task is to rework the startup code to obtain a GL context via EGL. EGL in turn requires a valid framebuffer handle to attach to, the precise form depending on the EGL implementation (ie. could be a Broadcom DispmanX handle on the R-Pi, an X11 window where X11 integration exists, or at least two other ways of attaching to fbdev). This would be a good opportunity to introduce a configure flag and #define to distinguish ES builds from normal GL. Note also that normal GL contexts can be obtained through EGL too (where a full GL implementation exists on the platform), so we can test EGL separately from GLES.
-
Okay, I'll leave that in your capable hands then :P
-
The other major task is to rework the startup code to obtain a GL context via EGL. EGL in turn requires a valid framebuffer handle to attach to, the precise form depending on the EGL implementation (ie. could be a Broadcom DispmanX handle on the R-Pi, an X11 window where X11 integration exists, or at least two other ways of attaching to fbdev). This would be a good opportunity to introduce a configure flag and #define to distinguish ES builds from normal GL. Note also that normal GL contexts can be obtained through EGL too (where a full GL implementation exists on the platform), so we can test EGL separately from GLES.
If you make it to no depend on X11 it might be easier to (later on) make it work on android too, if it can attach to the device directly and take over the framebuffer i think it will need little more than compiling it with NDK GCC and using android version of the libs.
So if you can avoid X11 better, if no, it does not matter.
-
On the R-Pi, the GLES implementation is not integrated with X11 at all. Indeed, X11 is unaccelerated. So to make FSO work on the R-Pi, I have to divorce it from X11 anyway.
Actually this means either divorcing it from SDL in that respect, or patching SDL to handle the new situation, since currently SDL is what provides the OpenGL context. Meanwhile SDL also provides mouse and joystick support, which are rather useful. Fortunately I think we can use those parts of SDL without using it for display.
-
I'll finally be getting my Pi in the next few days. I'll gladly volunteer it for any testing needed. Looks like there may not be a need though.
-
i finally managed to get me a pi. its in the mail.
-
Just got a few for the studio.
(https://dl.dropbox.com/u/6681376/2012-08-30%2012.43.58.jpg)
-
yea, im probibly gonna build a lipo powered switch mode psu for the thing. i want it to put out enough juice to power the pi (750ma), a small composite video screen (100ma), a powered usb hub (500ma per device), and a wifi dongle (unknown ampage) and a bluetooth dongle for input. im going to build a pitop. i cant get any dc-dc converter chips till next month though. i could do a 555 based supply but i dont want to trust my pi to a hack.
for the short term im just going to build a linear regulated supply. it ought to put out enough juice for the screen and pi.
-
Maybe this will be an option to the PI?
http://www.j1nx.nl/cubieboard-about-to-get-released/
-
these arm boards are popping up like daises. there has been a boom in the electronics hobbyist community where arm processors are becoming rabidly more accessible. once we have an arm build then it should be trivial to compile freespace to run on any of them. i think they just need to support opengl es and sdl, and most of them do already when used with an arm linux distro.
-
You should grab one of those old-school giant military laptops - you know, the olive-drab, metal, brief-case-sized computers they used to have. Dekker had a link for an old one once upon a time. With all the small hardware now, you could easily make a pretty substantial computer due to all the room in that case.
-
if you know enough about switch mode power supply design you could probibly build a lipo based psu that you could power a mini-itx mobo, an ssd and a smallish screen and throw in a keyboard and trackball mouse for good measure. just stick all that into a breifcase, and you have a laptop that is as good as a desktop. actually i want to do something like that with my pi.
-
these arm boards are popping up like daises. there has been a boom in the electronics hobbyist community where arm processors are becoming rabidly more accessible. once we have an arm build then it should be trivial to compile freespace to run on any of them. i think they just need to support opengl es and sdl, and most of them do already when used with an arm linux distro.
Not only that, i need to take a look at the avalible libs in the Android NDK toolchain, but if FS2 on OpenGL ES runs from framebuffer, running on Android should not that far away from that...
-
looks like the gpu on the pi is completely open source now:
http://hackaday.com/2014/02/28/raspberry-pi-gpu-goes-open-source-10000-bounty-for-quake-3/
does this help make a raspberry pi run freespace?