On Sun, 12 Jan 2014 00:35:55 +1000 David Seikel <onef...@gmail.com> said:
> BTW, in case it's not so obvious, when I say "big 3D game", I mean one > where the 3D world the game is set in is big, not a 3D game made by a > big company. Just in case that's confusing any one. 3D Tetris is not > a big 3D game. Skyrim is. I'm sure you are perfectly correct when it > comes to things like 3D Tetris, but I'm talking a much bigger scale. > > > On Sat, 11 Jan 2014 21:53:31 +0900 Carsten Haitzler (The Rasterman) > <ras...@rasterman.com> wrote: > > > On Sat, 11 Jan 2014 19:07:06 +1000 David Seikel <onef...@gmail.com> > > said: > > > > this is way too long. i just skimmed. > > You really should read it all. B-) > > > i'm going to cut it down to the gl supporting bits of efl you > > need/want for ALL cases of gl rendering with efl - virtual worlds or > > not. it's not relevant. > > It's entirely relevant, coz you are coming from the wrong perspective. > 3D performance is very important in big 3D games, coz this sort of app > has HUGE sets of 3d performance needs. Do you have any idea how many > triangles are in an entire world? Running the gears demo is an entire > different kettle of fish compared to running an entire 3D world. It > has a little more than three gears in it. Scaling is the issue, I want > a solution that scales to "shit, there's an entire world in there", but > this sort of thing seems to be beyond your grasp. i have more idea than you ever will know. i have WRITTEN 3d engines. long ago. on pentium systems.. when no 3d accel existed. i know perfectly well. and again - your "i must have pure hardware 3d or bust" line here is plain wrong. way back i had a 3d engine of my own - it was doing 40fps, in a window, in x11... qvga.... on a pentium 120. sure - not a huge # of triangles, but not too bad. and i hadn't don't a lot of optimizing. i know full well of what you speak. but again... you didn't READ WHAT I WROTE. use the preferred engine set, and if it's not available it still works, but is just slower. i'm rather tired of the discussion. > > 1. use the preferred engine set. end of story. it isn't broken. it > > works. i have a 3d modelling from christophe app proving that it > > works. it works now. today. check it out. go google for "slime" on > > github. you have messed up somehow in an unknown way to me - but it > > WORKS. look at slime. (and nice work christophe!) > > See Christophe's reply, seems he is having trouble to. He says himself > slime is not suitable for virtual worlds. "far from being usable", his > words, in the example you say proves it just works. read his reply. it has nothing to do with efl. it's just the stat of his modelling code. > If Elm preferred engine setting work as well as you said, then that > whole other thread would not have existed, coz that's exactly what I was > doing when it worked fine in EFL 1.7, and is what broke in EFL 1.8. > Now it works to hard set the engine instead of setting a preference, and > Cedric agrees that part needs fixing. I'll wait for him to fix it. > Cedric agreed it's broken, and not just coz he always breaks things. > End of argument. see his reply it is working for him. it's working for me. is it working for elementary_test? (you probably can't tell because it doesn't really run visibly faster - at least on any of my machines) it's not broken. i don't know what cedric is talking about. see christophe's mail. > > 2. you didn't get my point. you really didn't. don't FORCE the opengl > > engine down peoples throats. your entire view is based on the > > erroneous assumption that the preferred engine doesn't work. they may > > not have working gl driver support. just PREFER it. let the end user > > decide if they like the framerate or not - if you prefer opengl_x11 > > then it is used IF available... and it falls back to software_x11 if > > not. at least it still works. the above #1 handles that gracefully > > for you without fiddling with core config. > > You are not getting my point. You don't force software rendering down > peoples throats when they have hardware and expect it gets used. I'm > happy to provide software as an automatically detected fallback. No > way in hell am I supporting DirectX when OpenGL works fine on Windows. > Basically this sort of application is pretty much hard core 3D, it > needs 3D hardware, this is exactly the sort of thing that drives 3D > hardware development, big 3D games. you don't HAVE TO PROVIDE ANYTHING. fallbacks are ALREADY DONE FOR YOU. just use the preferred engine api. and trust me. second life is nor hard core 3d. it's primitive 3d. hard core 3d is very far from what you are doing. hard core 3d has shaders on everything with those shaders being 100's or 1000's of lines of GLSL, often runtime generated GLSL from templates, that provide specular lighting, bump/height maps, with multiple rendering passes for multiple shadow maps (self shadowing too) with filtering, bloom filters for glow, and other camera effects, motion blur, physics simulation with water, clouds (volumetric rendering) and insanely high resolution textures where you're pushing a 1gb of texture memory far beyond its limits. if your engine is anything close to second life, your 3d is far from hard core. if it's close to what i just described, then you are impressive as you're in the ballpark of unreal, latest id tech engines etc. which are massive undertakings. > Big 3D games don't "still work" with no big 3D hardware support. Why > don't you get that? Gears demo will work fine I'm sure, this is many > orders of magnitude bigger. Your point doesn't scale. How many modern > big 3D games have you seen that offer software rendering? How many are > happy to fallback to software rendering? Most, if not all, just say > "fuck off and buy a real computer". you still don't get the point. i shall say this one last time. do not FORCE it down the throats of people. use the preferred api and you get what you want. if you force it then you end up with something that doesn't even "boot". > > 3. elm_glview is just a convenience wrapper around evas_gl to make it > > easy to use and integrate. it's a good idea to use it if you want an > > easy life. > > If I can get this thing to work with ELm_glview then others will have an > easy life to. B-) > > I'm experimenting with both Evas_GL and Elm_glveiw. The earlier one > only worked with Evas_GL, and I'm still undecided if Elm is for me. So > I'm leaving that open for now. > > > 4. evas exposes an opengl-es2 api. any existing engine needs to be > > adapted to use this. that's pretty much the end of that. > > So basically what you are saying is that instead of just plain using an > existing 3d graphics library + EFL, people will have to port them to > EFL? Unity and Unreal users are just shit out of luck, dunno about unity and unreal users are paying customers and can ask for features like this as a paying customer. reality is both unreal and unity are entire game worlds of their own. they are not MEANT to work with efl, or gtk, or qt, or anything else. they include their own widget sets and more. so it's a moot point. fyi i've talked with people at unity3d who port to tizen... i have an idea of what's going on there. > OGRE, but Irrlicht is flexible enough that I might manage that. Still, whihc is all that matters to you as unless you want to PAY for the above and be stuck not able to ship source, you're doing an open engine port anyway. > gonna be a big task if you think it's REALLY needed. Something I'd much > prefer to avoid, coz it's a shit load of work, and there's no guarantee > upstream will accept it. Making my own private fork of a 3D graphics > engine isn't something I want to do, and it doesn't help any one else. as i said. it's impossible to do without wrapping. you want the ability to mix and match 3d and 2d within a window - then they essentially have to share context and that requires BEING the opengl lib - and thats is done bb evas_gl's api struct. > Think about that for a moment please, you are saying that existing 3D > engines need to be ported to EFL, coz EFL can't bend a little to > share. This will keep big 3D game developers away from EFL, they like > their Unity or OGRE. it's not a matter of bending. it CANNOT BE DONE (unless you want to pay the price of rendering to a foreign buffer/pixmap and then importing it via native surface - that of course is an extra buffer copy cost which can hit your framerate anything from halving it through to maybe a 10% hit). > While it's true I'd love to see a decent 3D graphics engine built on > EFL (and built in C), as I pointed out that's one big fucking job, as > big as writing EFL in the first place. How long did it take to write > EFL? I'm not gonna write one from scratch. I have far too much else > to do with my virtual world project. Working with existing 3d graphics > engines is what big 3D game developers have to do. as above. it's done the only way it can be done. the port is trivial "sed" work pretty much. find the gl draw api's and add a macro in front. replace egl/glx and window creation etc. with evas_gl/elm glview. you have to port to work within the efl mainloop anyway - you have to port input events anyway. a port is necessary no matter what. > > 5. the engine will need to be adapted so the draw function is > > callable - eg by elm_glview. then it's easy to switch where rendering > > happens. evas offers a fast path to avoid buffer copies and make the > > gl view draw part of the evas rendering path directly. this would > > offer almost zero overhead vs doing it directly with egl/gles etc. to > > your backbuffer yourself, BUT gets you the bonus of having your 3d > > view as part of a larger scenegraph. combine 2 or 3 of them in a > > single window. overlay with evas objects or elm widgets for hud etc. > > all for free. this also implies the engine has to integrate to the > > efl mainloop etc. of course. > > Same as 4, means the 3D graphics engine needs to be ported to EFL. > > > 6. no not everyone has 3d drivers on their desktop - or not ones that > > can work with efl. the laptop next to me has an ancient intel > > chipset. it can't be used by efl at all. it doesn't do shaders > > (opengl2). it is one of my test boxes. no not everyone has drivers. i > > can point out a cyrix/via based netbook i ditched not long ago... no > > accel. can i point out all the recent efforts of people getting linux > > on the baytrail tablets/laptops? they can get it up.. without any gl > > accel. but accel simply isn't working for them. same situation as the > > arm soc angle. > > People with no 3D graphics drivers on their desktops aren't gonna be > playing big 3D games. B-) > > And you obviously didn't read the parts where I did talk about where > software FALLBACK is actually a good thing, sometimes. But only for > me, other big 3D game developers will probably just laugh and walk away. you keep going on about it as if efl doesn't support gl and that it must have it in pure hw gl ONLY or nothing can ever be done. that's just plain wrong. i'm done with the topic. i know perfectly well of what i speak. i've written renderers. > > 7. i have no idea how you shared a gl context with efl with irrlicht > > and your playground, but if you didn't use evasgl/elmglview.. you > > were playing with "it's not meant to work and you just had it by > > luck". > > As I mentioned in my email, it was a new GL context created by Evas_GL, > it's the window surface that was shared. i don't have your code. i don't know. you have our sample code that works. go from there. > > look at the elm test code for gl - the tests work. look at slime as > > above. it works. > > Elm GLview test and that Evas_GL example are what I have been looking > at. My playground app is basically cut and paste huge swathes from > those two examples. > > > that's what you need to know. :) > > Basically that boiled down to - for this sort of application, people > need to port their 3D graphics engine to EFL. That's a big deal breaker > for big 3D game developers, and I expect there wont be many big 3D games > written with EFL. Maybe in two or three decades after I've done one, > a few people might follow in my foot steps. I was hoping to keep it > down to one decade. lol if the big 3d engine makers want to do it - it's easy enough. i've spoken with at least one company. end users and game devs will not do the port -because they don't care. they already have the full world including supported hud and widgets from the engine. they don't want, or need efl. the people who need it or want it are those without a hud or a very poor one and to them it provides a porting layer between gl and gles2 (saves time doing it yourself), provides all the 2d hud, widgets and controls, and also all the other things you have to ADD to your engine - mainloop, timers, animation and other things. if they don't need or want any of the above, using efl is a royal waste of time for them entirely, and it is a waste of our time to work on accomodating them wasting their time. if the engine is missing things that efl can help with/provide - then it's a cost benefit analysis. for the effort of porting to efl (not just rendering - that's probably one of the easier things as described, but also mainloop and input event infra and more which would end up most of the work), you get all the other bits of your engine filled in with ease and do not have to remake them yourself. > > > I'm starting this fresh. Maybe if I specify what it is that I'm > > > doing in terms that any one can understand, we might actually get > > > somewhere. > > > > > > I want to dedicate my life to making virtual world software great, > > > so I'm passionate about this subject. I'm also passionate about > > > EFL, so I want to use EFL for the infrastructure and the UI. So > > > far Elementary has not impressed me, but at least I'm still trying > > > it out. > > > > > > There's lots of big parts to what I want to do, and I really don't > > > want to take a decade out from my main goal to write one of those > > > big parts from scratch each time. So integrating already written > > > big parts is important to me. I'm 53 this month, I'm not getting > > > any younger, and I want to finish this before I turn senile. I > > > know, some of you think it's too late, I'm already senile. B-) > > > > > > TL;DR - a modern 3D game lives and breaths by it's frame rate, and > > > they get their good frame rates by using hardware 3D acceleration. > > > Modern 3D game developers want access to the 3D hardware if it's > > > available, by default. They also want to use a 3D graphics engine > > > written by some one else. If they want to use EFL, they want that > > > AND EFL UI goodness overlayed on top. So it's important for these > > > parts to cooperate and perform well. How do we do that? > > > > > > > > > WHAT ARE VIRTUAL WORLDS - > > > > > > Virtual worlds are not a game, and not just 3D modelling software. > > > They are very game like in the basic technology though, and I have > > > lots of trouble trying to explain to people how they are not > > > games. But since this discussion is about the technology, and the > > > lack of actual game mechanics is not important at this level, I'll > > > just bite the bullet. Lets discuss making a game. Coz lets face > > > it, if we can get this all sorted out, 3D game makers might start > > > using EFL. > > > > > > Second Life (SL) is a popular virtual world, but it sucks in so many > > > ways and is a walled garden. It's the basis of what I'm trying to > > > do though. I'm trying to make it not suck, and not be a walled > > > garden. There is a lot they got right in their concepts though, one > > > reason why it's popular. I want to use the open source SL viewer, > > > and the open source SL server clone (OpenSim) as "it already works" > > > structure that I will rip great chunks out of and replace with sane > > > code. That way I'll always have something that works while I take > > > many years to make it not suck. > > > > > > Skyrim is a popular open world / sandbox RPG game. It consists of a > > > huge 3D world (size of a modern large city, filled with all the > > > minutia you would expect to find in a city and country side), with > > > wonderful 3D graphics, really large draw distance, and GUI elements > > > on top of that. The player is free to wander anywhere in this huge > > > 3D world at any time. Hopefully most people here have played this > > > or similar games, or know about this sort of game. Big, open, 3D, > > > world. Rendered in real time, but with some stuff pre rendered. > > > > > > Virtual worlds are very similar, except there's no actual game > > > system on top of it. Also, in virtual worlds multiple people can > > > connect over the network to the same world, and interact. People > > > can build their own stuff in world, in fact a lot of the time the > > > entire world is user created. People can script the world. It's > > > all one huge world filled with all the sorts of crap the real world > > > is filled with. Landscape, trees, people, animals, monsters, > > > buildings, sky, moving clouds, water, waves, stars, sun, moon, > > > pots, pans, plates, cutlery, vehicles, weapons, jewellery, clothes, > > > etc. Oh and hair, OMFG hair, the hair on one person can be a huge > > > resource sucking hog, let alone a crowd of people. Then there is > > > me and my beard. All fully textured. There is particle effects, > > > materials, transparency, and all that other usual 3D rendering > > > fanciness. All of this is rendered to the screen as 3D. In real > > > time, no pre rendering. Across the Internet. > > > > > > On top of these beautiful, rendered in real time, big complex 3D > > > worlds is some sort of user interface. I want to use EFL for this > > > UI. Actually I want to script the UI with Lua. A also want to > > > script the world with Lua. I want my users to be able to script UI > > > and world with Lua in the same script. I want to convert the > > > horrid SL XML UI crap to Edje Lua, preferably automatically, but > > > these last things are for later, and not part of this discussion. > > > > > > Sooooo, let's talk about writing Skyrim in EFL, since I think more > > > people will understand that than understand virtual worlds. Hell, > > > most people that use virtual worlds don't understand them. People > > > understand games. The tech challenges are the same. Let's pretend > > > the Skyrim developers fell in love with EFL and want to write > > > Skyrim 2 with EFL. How do they do that? How do we help them? > > > > > > > > > PERFORMANCE - > > > > > > This is the big sticking point in the previous discussions. Skyrim > > > is a 3D game. Rendering the 3D world fast is VERY VERY IMPORTANT. > > > Yes, software fallback for rendering for UI is acceptable, but not > > > for the 3D world. For the 3D world rendering it is of utmost > > > importance that if the user has 3D rendering hardware, that it gets > > > used by default. Ask any gamer, half the time they'll talk about > > > their hundreds of FPS that they get on their gaming rig, and how > > > they tweaked things to get it higher. Never mind that the human > > > eye only operates at less than a hundred "frames" per second. > > > Though in the end, if the game can render at hundreds of frames per > > > second, that means it's spending less time rendering, and can have > > > more time for other things. > > > > > > Raster - this isn't bringing up a SOC where the graphics drivers are > > > not written yet and 5 FPS is OK for now. The drivers exist already > > > on peoples desktops. This isn't a 3D modeller where showing simple > > > things slowly is OK. This is not a ten year old game where 10 FPS > > > is good. This is NONE of those things where software rendering is > > > any sort of solution. I know you are fighting for those things, > > > this is NOT that fight. Please drop that fight in this discussion > > > and think about this real problem - modern big 3D games on desktops. > > > > > > Every modern 3D game tries to use 3D rendering hardware. Almost > > > all of them just flat out refuse to run if they don't find any. > > > Try telling a modern 3D game writer or player that software > > > rendering is good enough, and you WILL get laughed at. Software > > > rendering is not an option, forget about it. Sure it works OK for > > > the UI, but a 3D game that shows just the UI is unusable, it's the > > > rendered 3D scene behind the UI that's important. On the other > > > hand, a 3D game that has the UI in a separate window is also not > > > good, especially when the game is fullscreen and there are no > > > external windows. 3D scene and UI need to be combined. > > > > > > (As an aside, yes I do intend to have software rendering as a > > > fallback option for those cases where the user has no 3D rendering > > > hardware. It's a fallback, not the main aim. In such cases the > > > user expects their crappy ten year old student laptop to perform > > > slowly anyway. But for people with real 3D hardware, it should be > > > used by default. People expect their thousands of dollars high end > > > gaming rig to perform fast. People in the middle expect performance > > > in the middle, not software performance by default.) > > > > > > > > > Let me be perfectly blunt - CAN'T DO 3D GAMING WITHOUT 3D HARDWARE > > > SUPPORT. It's just entirely pointless, and a waste of time. Any > > > arguments to the contrary will be ignored. That's not what this is > > > about. > > > > > > > > > UI - > > > > > > I want to use EFL as the UI. I'm still not convinced yet about > > > using Elementary, but I am trying it out. I could use raw Evas, as > > > I have done in previous stuff I have written. EFL these days uses > > > GL of various sorts deep within it's guts, even if it's just > > > software rendered GL. Eventually I want to use Edje Lua, but Edje > > > Lua is my problem to solve anyway. > > > > > > (I did a lot of the current Edje Lua implementation, driven by my > > > need for it in an older project that is finished now. I intend to > > > drive further Edje Lua work with this Skyr.. er I mean virtual > > > world project. That's why I already have experiments for doing > > > world scripting using EFL and Lua.) > > > > > > For the Skyrim 2 game there will be UI elements rendered on top of > > > the 3D scene. There will be "windows" of some sort rendered on top > > > of the 3D scene. So the high performance 3D rendering system and > > > the UI rendering system have to cooperate to render to the same > > > surface. > > > > > > Raster - you mentioned a couple of times that having multiple GL > > > contexts is a slow resource hog, so sharing one makes a LOT of > > > sense. Especially since performance is important. > > > > > > (Also I intend my system to have windows internal to the main 3D > > > window, and to allow those windows to be "torn off" and used as > > > first class windows in what ever window manager the user is > > > running. So some sort of internal window manager running in the 3D > > > scene is also part of my goals. I know we have one, but I've not > > > looked at it yet. No idea if it can work with Elm. This is not > > > important for now.) > > > > > > > > > 3D GRAPHICS ENGINES - > > > > > > Writing a full blown 3D graphics engine that is suitable for modern > > > big 3D games like Skyrim is a very big and hard job. That's why > > > there are not very many of them already. There's about as many > > > full blown 3D graphics engines as there are UI toolkits like EFL. > > > We all know how hard it was to write EFL, and how many years it > > > took our team to do so. But such things are needed, and most modern > > > 3D games use them. In fact most modern 3D games use one that was > > > written by someone else - Unity, Unreal, OGRE, Irrlicht, etc. Coz > > > it's too hard to write your own. > > > > > > Writing a big complex 3D Skyrim type game, or virtual world system, > > > is hard and complex enough by itself. I'm only one man, I'm not > > > gonna write my own 3D graphics engine as part of EFL. I doubt if > > > any one else wants to either. I don't think we want a full blown > > > 3D graphics engine inside EFL. Though I would love a proper full > > > blown 3D graphics engine that is based on EFL and suitable for big > > > 3D games, but that's just a pipe dream. Hell, I'd be happy with > > > one written in C, but C++ seems to be the language of choice for > > > the people that write them. > > > > > > So getting EFL to live with third party 3D graphics engines will be > > > needed for Skyrim, and for virtual worlds, and 3D games in general. > > > Performance needs to be good. Performance needs to be great. > > > > > > These third party 3D graphics engines often allow various backends, > > > OpenGL, DirectX; and some work on various OSes, Linux (if you are > > > lucky), Mac (sometimes), and Windows (crap, but it's what "most" > > > people use). I want to support Linux, Mac, and Windows. > > > Eventually I'll add Android. I just spent too much money an > > > genuine Apple hardware specifically so I can do virtual world > > > development (and EFL porting) for Mac OS X. Maybe I'll support > > > iPhone in future to, but I have to get over my last Apple spend > > > first. lol > > > > > > OpenGL actually works good on all those operating systems, so I > > > really don't mind sticking just with OpenGL, in fact that's my > > > plan. It works, it's everywhere, anything else is just Yet Another > > > Distraction in my life goal. > > > > > > I looked at open source 3d graphics libraries, I specifically looked > > > for one that was good on low resource and ancient hardware. OGRE > > > didn't fit my requirements. Irrlicht did. I was particularly > > > impressed with the Irrlicht software renderer. > > > > > > Raster - See? I can live with software renderers, but there's a > > > place for such things, and it's not the main aim here. > > > > > > No doubt people will want to use OGRE, or Unity, or any of the > > > other 3D graphics engines that are popular. They will have the > > > same issues. > > > > > > > > > WHAT I'M TRYING - > > > > > > I have a playground app where I'm trying to get EFL GUI and > > > Irrlicht to play together nicely. So my previous experiment > > > managed to get EFL 1.7 and Irrlicht to share a GL context and > > > render to the same window. This was working fine, and I started to > > > implement more of the basic code for the 3D world. This playground > > > app is also where I'm trying out Elm, to see if it will work for > > > me. So far, I'm not impressed, and really annoyed at the excess > > > screen space used, but that's another topic for another place. > > > Yes, it's a theme issue, me writing a them is Yet Another > > > Distraction. > > > > > > With EFL 1.8 this playground app stopped working. A bunch of things > > > stopped working, and I've spent a lot of the last week trying to get > > > them to work again. > > > > > > I'm trying both Evas_GL and Elm_glview, with #if around those parts. > > > Trying to see which one works best for my goals. Both Evas_GL and > > > Elm_glview bit rotted. That last thread of mine went over that, it > > > wasn't the lack of osmesa, get over that. I've fixed my Elm_glview > > > usage, but that's a hack to select X11 OpenGL (not "prefer", that > > > only works if the user selected OpenGL in elementary_config, which > > > is a silly thing to ask game users to do). Cedric said he'll work > > > on that part of Elm to make it better. I'm prepared to wait for > > > his fixes. This is just a playground to see if I can get everything > > > to play nicely. > > > > > > Given the previously mentioned need to share GL context, there's two > > > ways to go about it. EFL creates the context and shares with > > > Irrlicht, or Irrlicht creates the context and shares with EFL. > > > Irrlicht had Windows code to use a GL context created elsewhere, > > > EFL 1.7 may have, it was not well documented enough for me to > > > figure out, and the guts of EFL GL code is a twisty little maze. > > > Irrlicht was not happy sharing out it's created context in my first > > > experiment. Evas_GL has API for creating GL context, and I patched > > > up Irrlicht so Linux could share context like Windows can. This > > > last is what worked, but obviously not in the Elm_glview version. > > > > > > Yes, I'm aware that this is using multiple contexts rather than > > > sharing a context. One step at a time, but still want to get to > > > the point where the EFL context is shared. > > > > > > Right now in my playground app and latest EFL git I have Elm_glview > > > working showing rotating gears. Evas_GL isn't working now, but now > > > that Raster fixed up the Evas_GL example to work, I can refer to > > > that to get Evas_GL version working again. It was pointless > > > referring to a broken example. Once I have done that I'll see if I > > > can get the Irrlicht integration working again. That might just > > > work anyway once Evas_GL works again. > > > > > > > > > GETTING THERE - > > > > > > As mentioned above, this playground app creates a new GL context, > > > but there's still the EFL context buried somewhere, and Raster > > > mentioned a couple of times that having multiple contexts is a > > > bitch for performance. So, how do we deal with that? > > > > > > "Just use software rendering" that I was constantly hit over the > > > head with yesterday is not an option. Serious 3D game developers > > > will just walk away, for the reasons I detailed above. Certainly > > > you can't do Skyrim that way. Virtual worlds can use software > > > rendering as a fallback, but it's still important to use actual 3D > > > hardware by default if it exists. With no jumping through hoops > > > for users or developers. > > > > > > Use multiple GL contexts? While this worked in EFL 1.7, and I > > > might be able to get it to work in EFL 1.8, it's likely to be a > > > performance bottleneck if what Raster says is true. Frame rates > > > are gold for 3D games, this sort of lower performance will be a > > > deal breaker for developers, coz it's gonna be a deal breaker for > > > game players. All that extra memory usage from multiple contexts > > > that Raster mentioned is also a problem for me. I want my result > > > to still work on resource constrained devices, just like EFL. > > > > > > Share the EFL context with others? This seems to be controversial > > > enough that people keep trying to side track me with this "use > > > software rendering" and "make your game players install software > > > rendering so their hardware rendering works" nonsense. Bottom > > > line, if this can't be done serious 3D game people wont take EFL > > > seriously, and that's a big shame considering what EFL can do for > > > 2D game people. EFL now insists on using GL, but wont share. > > > > > > Raster - in an earlier thread where you detailed the issues with > > > using multiple GL contexts, we discussed sharing. You implied it > > > could be done. Even though this is where you went through the > > > problems of multiple contexts, and I thought that's one of the > > > things we were talking about, perhaps your half of the conversation > > > meant "multiple GL contexts is a bitch, and Evas_GL only supports > > > using multiple contexts" but you really did not mean "multiple GL > > > contexts is a bitch, and EVAS_GL supports sharing it's one gl > > > context with apps". > > > > > > > > > SOOO, PRETTY PLEASE WITH SUGAR ON TOP - > > > > > > Can we have some support in EFL for the sorts of 3D game developers > > > that write stuff like Skyrim, or pretty much any modern big 3D game, > > > or even virtual worlds? I'm happy to do the grunt work to make EFL > > > examples and write EFL docs, that's exactly what I'm doing now. But > > > the deeper support is needed in EFL, and I'm not sure it's there > > > yet. It certainly is not stable in the experiments I've been trying. > > > > > > If this sort of support is there already, then how is it done? What > > > am I missing? > > > > > > > > > /me goes back to trying to get Evas_GL in my app working again with > > > EFL 1.8, then the Irrlicht integration. > > > > > > -- > > > A big old stinking pile of genius that no one wants > > > coz there are too many silver coated monkeys in the world. > > > > > > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
