[2.1] Ogre 2.1 official release goals

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


Post Reply
123iamking
Gremlin
Posts: 152
Joined: Sat Aug 12, 2017 4:16 pm
x 4

[2.1] Ogre 2.1 official release goals

Post by 123iamking »

Hi everybody,

I know that to official release Ogre 2.1, Ogre 2.1 must support popular cross-platform, according to this article
I really want to work more on DERGO, but GLES3 working again would mean three platforms being compatible again (OS X, Android, iOS) and once we have that in the bag, we might start talking about an official 2.1 SDK release date. Can’t say that isn’t tempting…
But , If Ogre 2.1 is finally compatible with Android, then BAM - official 2.1 SDK release date is set. Or Is there any other goals? I'm just asking this out of curiosity :D

Thanks.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [2.1] Ogre 2.1 official release goals

Post by dark_sylinc »

Hi!

To be honest, 2.1 has been extremely stable by now; and if we haven't seen an official release yet it's because:
  • I haven't had the time.
  • The CMake scripts (particularly the "INSTALL" scripts, which are used to make the SDK) need a full overhaul. Even if I were to use these despicable, old install scripts; I'd need the time to ensure everything works as intended and conforms out our quality standards. Again it's a problem of time
As for Android support, I have sort of given up on that. Last time I tried, I got deadlocks inside the driver while compiling one of our more complex PBS shaders; then on another phone it just outright crashed in Texture manipulation stuff.

The overall Android driver quality on GLES3 is extremely poor, and comparing notes with other Android devs, it's not just us. Getting Ogre 2.1 working flawlessly on Android would be a dream, but frankly, they need to get their shit together.

Just to be clear: I haven't fully given up, but it is quite discouraging that nothing really works as it should; which means not having Android support in Ogre 2.1 isn't a reason delaying the SDK release (unless tomorrow someone comes with a huge breakthrough in Android/Ogre compatibility that would warrant waiting).

Cheers
Matias
User avatar
Mako_energy
Greenskin
Posts: 125
Joined: Mon Feb 22, 2010 7:48 pm
x 9

Re: [2.1] Ogre 2.1 official release goals

Post by Mako_energy »

I recall Hotshot5000 making an effort in this area about a year ago and making some progress. Was his approach something Ogre couldn't integrate? Or did he hit other roadblocks and stop?

Also, realistically...how likely do you think it is that driver support will improve given the abundance of other games on Android that make it work? It's been my observation with these types of things that support only meaningfully improves when 1) a huge triple AAA game comes out and needs the support to work, or 2) a new platform comes out (in this case when/if GLES4 becomes a thing).
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [2.1] Ogre 2.1 official release goals

Post by dark_sylinc »

Mako_energy wrote: Sat Nov 11, 2017 11:00 pm I recall Hotshot5000 making an effort in this area about a year ago and making some progress. Was his approach something Ogre couldn't integrate? Or did he hit other roadblocks and stop?
Sadly, that's what I tried.
On one hand, what I saw was very impressive. On the other hand, quite disappointing from Android's behalf.
Hotshot5000 did an excellent job. Tutorial samples work, other samples work. It's incredible. But try something as "simple" as PBS Materials sample and you get driver deadlocks.
Mako_energy wrote: Sat Nov 11, 2017 11:00 pm Also, realistically...how likely do you think it is that driver support will improve given the abundance of other games on Android that make it work? It's been my observation with these types of things that support only meaningfully improves when 1) a huge triple AAA game comes out and needs the support to work
Android has many problems:
  1. GLES3 is fundamentally flawed. It could be fixed with a couple extensions but no one lifts a finger. We sit down on >1Ghz quad core devices with more computing power and RAM than an Xbox 360 and PS3 (though not bandwidth) and all that power is locked away because of moronic API and poor driver quality.
  2. Of all the vendors (Qualcomm's Adreno, ARM's Mali, Imagination's PowerVR, NVIDIA's Tegra) the only one with decent drivers is NVIDIA. Second place far away (it's buggy) goes to PowerVR. Sadly, those two vendors combined make for a very tiny fraction of the Android market. ARM and Qualcomm compete for the worst drivers ever. And they've got huge market share.
    The difference of what you can do with a PowerVR Series 6 on iOS' Metal and Android's GLES3 (which is basically the same HW) is staggering.
  3. Android vendors profit by selling phones, not updates. Even if magically these poor vendors made a superb driver release, there would be millions of devices out there that will never get the update.
  4. Most games out there aren't AAA. GLES2 is just fine for that. It's a catch 22 problem. AAA won't care unless driver situation improves significantly, driver makers won't care unless AAA vendors show they suck. Today's notion of AAA is Asphalt Xtreme.
  5. Vulkan is the great replacement. Problem is:
    1. There's still phones being manufactured today that don't support Vulkan. Good lord, some of them run on Android 4.4.4
    2. Vulkan is the other extreme, it's hard.
    3. I'm hearing from Vulkan devs that Android driver vendors are also fu**ing Vulkan up, they're buggy too. HOW??? Vulkan is supposed to be easy for the driver to make!
  6. Android makes up for its high piracy rates and low ARPPUs with its massive market share. That means I don't give a jack 1% of the userbase has good, modern drivers that can run my app. Nougat's and Oreo's market share stands today at 18% of market share combined. You need both Nougat and a Vulkan capable GPU to run Vulkan.
I've been told Android 8 will come with user-mode installable drivers, so the future may be bright (basically, download your drivers from Google Store, so even if your manufacturer has long abandoned your model, you may still receive updates*)
(*) I'm not making big hopes though. I can already see GPU drivers in the future not supporting older Android versions and then we're back to square one.

But until Android 8+ becomes mainstream... it could be a decade from now on.
Mako_energy wrote: Sat Nov 11, 2017 11:00 pmor 2) a new platform comes out (in this case when/if GLES4 becomes a thing).
Maybe. Google should be waaaaay more aggressive with their conformance tests.
Really this is a problem of money. As long as Google's main focus is ad revenue (which any phone will do), phone vendors' main focus is selling newer phones, and Candy Crush-like games drive game sales (which GLES2 is enough), there is really no incentive.
Like you said, if tomorrow a new (cheap) competitor appears and starts stealing sales because it has much better and efficient GPU utilization (games aren't the only thing powered by GPUs, GUIs are too!), or NVIDIA/AMD/Intel enter Android and dominate the market, then I don't think there will be much improvement. I hope I'm wrong.
123iamking
Gremlin
Posts: 152
Joined: Sat Aug 12, 2017 4:16 pm
x 4

Re: [2.1] Ogre 2.1 official release goals

Post by 123iamking »

Wow, Android is really a problem. But then it makes me really curious: How do CryEngine, Unreal Engine & Unity deal with this problem? (Hey, CryEngine & Unreal Engine allow us to access their source now). (I'm very new to Graphic programming :p please pardon me if this question is stupid)
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [2.1] Ogre 2.1 official release goals

Post by dark_sylinc »

123iamking wrote: Sun Nov 12, 2017 2:09 pm Wow, Android is really a problem. But then it makes me really curious: How do CryEngine, Unreal Engine & Unity deal with this problem? (Hey, CryEngine & Unreal Engine allow us to access their source now). (I'm very new to Graphic programming :p please pardon me if this question is stupid)
I don't know about CryEngine.

I know that Unity is mostly GLES2 with some GLES3, which is pretty limited in both what you can do and in performance. Furthermore Unity has A LOT of resources, I know the devs have said they swear a lot about Android, and they have a A LOT of per-device workarounds because something breaks on some device(s).

As for Unreal Engine, I don't know much, but I do know that anything visually and performance impressive for Android that has came out of them has been running on Vulkan. So, those 100 guys with a phone that can run it can definitely enjoy the experience. The rest, even if their HW specs could definitely run that, can't.
One of the most impressive (IMHO) UE4-powered games like Evhacon 2... it has a lot of 5 star ratings, but just take a tour over the comments: "laggy" "too slow" "crashes" "Not working in old devices" "too long loading". The amount of 1-star ratings is really high (14.20%)
There's nice looking UE4-powered games with good ratings. Not everything is gloom and doom, but basically Android is the worst platform to maintain and support, specially with scarce resources like us.
User avatar
Mako_energy
Greenskin
Posts: 125
Joined: Mon Feb 22, 2010 7:48 pm
x 9

Re: [2.1] Ogre 2.1 official release goals

Post by Mako_energy »

That leaves just one direct question. Whats the prospects of GLES2 running in Ogre 2.1? Last I heard it was even more bleak than getting GLES3 running...which is...not good. =\

Also, getting slightly back on topic since it was mentioned in the first post of the thread...how's DERGO?
frostbyte
Orc Shaman
Posts: 737
Joined: Fri May 31, 2013 2:28 am
x 65

Re: [2.1] Ogre 2.1 official release goals

Post by frostbyte »

just adding some random thoughts and observations from an outsider( still using 1.10 )
dark_sylinc wrote: Sat Nov 11, 2017 8:32 pm Hi!
As for Android support, I have sort of given up on that. Last time I tried, I got deadlocks inside the driver while compiling one of our more complex PBS shaders; then on another phone it just outright crashed in Texture manipulation stuff.

The overall Android driver quality on GLES3 is extremely poor, and comparing notes with other Android devs, it's not just us. Getting Ogre 2.1 working flawlessly on Android would be a dream, but frankly, they need to get their shit together.

Just to be clear: I haven't fully given up, but it is quite discouraging that nothing really works as it should; which means not having Android support in Ogre 2.1 isn't a reason delaying the SDK release (unless tomorrow someone comes with a huge breakthrough in Android/Ogre compatibility that would warrant waiting).

Cheers
Matias
i think that not having android support is very unattractive for cross platform developers while having it is very attractive...
i don't think anybody expects one person to do development+ QA and bring android port to perfection, one needs a team for that...
last time i checked ogre was open-source , and that comes with all the benefits of having a team of developers aka ogre-community/users
working with you on the project, and that include QA and fixing stuff, so my suggestion is to make it work on just one mobile phone+emulator, merge it and start taking pull requests, as long as developers/users are aware of ogre-gles3 situation and status it should be fine.
Most games out there aren't AAA. GLES2 is just fine for that. It's a catch 22 problem. AAA won't care unless driver situation improves significantly, driver makers won't care unless AAA vendors show they suck. Today's notion of AAA is Asphalt Xtreme.
guessing that by AAA you actually mean 1st/3rd person view games with pretty scenes and convincing lights
i don't think phones "have the juice" for this kind of AAA and besides that i don't think there is a crowd for that since there other limits as battary draining, screen-size and lack of good AAA gaming controls
some say that mobileVR is just around the corner( occulusGO ), not holding my breath for it, but its a potential market that might boost...
not sure if this second mobileVR wave/ripple would bring better android GLES3 support or vulkan adaptation...
anyways with cheap high-end chinese phones sells gaining momentum i guess we'll see the remaining 36% GLES2 phones diminish rapidly
but GLES3 working again would mean three platforms being compatible again (OS X, Android, iOS)
what about webGL2, no plans for web support? http://webglstats.com/webgl2
i wonder whats the status of webGL2 cross platformability, or in other words: "how bad is the situation?" :lol:
the woods are lovely dark and deep
but i have promises to keep
and miles to code before i sleep
and miles to code before i sleep..

coolest videos link( two minutes paper )...
https://www.youtube.com/user/keeroyz/videos
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [2.1] Ogre 2.1 official release goals

Post by dark_sylinc »

frostbyte wrote: Tue Nov 14, 2017 6:22 am guessing that by AAA you actually mean 1st/3rd person view games with pretty scenes and convincing lights
i don't think phones "have the juice" for this kind of AAA and besides that i don't think there is a crowd for that since there other limits as battary draining, screen-size and lack of good AAA gaming controls
Yeah we probably should define what everyone means by "AAA".
Simply put, most phones out there have more "juice" than the PSP, 3DS, PS Vita and similar handheld consoles.
Heck, some Android devices may even be able to compete with the Nintendo Switch in terms of raw power. But all that power locked away...
frostbyte wrote: Tue Nov 14, 2017 6:22 am not sure if this second mobileVR wave/ripple would bring better android GLES3 support or vulkan adaptation...
anyways with cheap high-end chinese phones sells gaining momentum i guess we'll see the remaining 36% GLES2 phones diminish rapidly
Really the problem is vendors still manufacturing "cheap" GLES2 phones.
In Desktop-land, we got rid of the problem thanks to Intel taking over the IGP market, and finally start making decent IGPs with their Intel HD line around 2009. While far from being the best of the best, it increased the low bar a lot. All these cards support DX10 at a minimum, and a lot of them support DX11 very decently.
We only need to care about lowering quality or removing features so these devices can still render at decent speeds. An entirely different beast is when you have to workaround GPUs because a green square appears at the bottom right corner for no reason, lights flicker for unknown causes, and the game crashes when you look directly at the sun.
what about webGL2, no plans for web support? http://webglstats.com/webgl2
i wonder whats the status of webGL2 cross platformability, or in other words: "how bad is the situation?" :lol:
Oh that's right! I forgot about WebGL2! That situation is actually much brighter (as long as your browser is running in a desktop, be it Windows or Linux, I dunno about macOS). The changes HotShot5000 did to our GLES3 works perfectly fine on Desktop.
You reminded me that perhaps I should focus on integrating HotShot5000's branch not because of Android, but because of WebGL2.
Mako_energy wrote: Mon Nov 13, 2017 8:53 amAlso, getting slightly back on topic since it was mentioned in the first post of the thread...how's DERGO?
It's doing fine! I guess?
Sadly I haven't had more time to work on it. It's just sitting in standby there. In fact I have yet to review a PR where someone got DERGO working on macOS using Metal :)
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.1] Ogre 2.1 official release goals

Post by xrgo »

dark_sylinc wrote: Tue Nov 14, 2017 2:31 pm Mako_energy wrote: ↑Yesterday, 2017 4:53 am
Also, getting slightly back on topic since it was mentioned in the first post of the thread...how's DERGO?
It's doing fine! I guess?
May I say something a little discouraging...?
I was really really exited about DERGO (since I use blender files in my engine, I edit my materials in blender too)... but... now Blender 2.8 with Eevee is around the corner and I think efforts should be put in making Ogre look closer to Eevee and make a good exporter or blend loader. I think it would be better if you just do all your work in blender and then expect that in Ogre would look the same... or substance, quixel, etc they are all following the same standard.

Saludos!
Hotshot5000
OGRE Contributor
OGRE Contributor
Posts: 226
Joined: Thu Oct 14, 2010 12:30 pm
x 56

Re: [2.1] Ogre 2.1 official release goals

Post by Hotshot5000 »

Adding my 2 cents:

While the situation on Android land sucks due to bad drivers, I see the situation slowly improving. For the game I'm working on I'm targeting a late 2018/early 2019 release. By then, the situation will only have improved and if you are working on AAA project, I wouldn't focus so much on making it work on 200$ phones (even if those are the most common Android phones) because those people might not be as willing to buy my game for say 10$ as somebody who owns the latest Samsung Galaxy. The neat thing is that the latest Pixel phone, Galaxy etc. (expensive phones) already have pretty decent support for GLES 3.2/Vulkan from what I understand (haven't tested any of them). So what I am trying to do is cover the desktop, iOS and high-end Android (maybe also the mid-level in the future when mid-level will get better support). One of the advantages of targeting high-end devices is that there are fewer of them so you don't have to test on tons of devices.

Making Ogre work on GLES2 is painful from an implementation perspective and you also lose most of the advantages of the Ogre 2.1 branch. Not to mention now you have to test on hundreds of shitty 150$ devices. So I don't care about that market. Of course, if anybody wants to contribute a GLES2 branch I am not going to be against it, but right now, when I'll have some spare time, I'd rather focus on getting Vulkan working in order to target the future Android devices.

From what I've heard, Samsung is the top seller of smartphones in the world except in USA (where Apple is number one). If that is true you could target Apple and Samsung for the best return on investment and not worry about all those Chinese crapphones. The buyers of those weren't going to buy your game anyway. We're not there yet, but I hope that by 2020 we will have phones with good Vulkan support in the 400+$ price range, so having a Vulkan backend by then would be a good thing. GLES3 was always going to be a stopgap solution.

Also, almost forgot, in the coming months I will be getting my hands on multiple Android devices to test the GLES3 branch and make adjustments. I want to make sure that at least the high-end devices are well supported. Right now I've only tested on a Nexus 5. By the end of the next year I want to be confident that the GLES3 branch is stable for most well known Android devices.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [2.1] Ogre 2.1 official release goals

Post by dark_sylinc »

I can't say I agree with your analysis, but dammit, I want to believe it. Plus, there's WebGL 2.0
I guess I should look more into merging your branch back to us, focusing on GLES3, irrespective of Android.

Something I'm curious to see is Ogre 2.2 + Android; even though it's WIP, the new texture manipulation code is much cleaner, to the point and should theoretically cause much fewer bugs with the drivers.
xrgo wrote: Tue Nov 14, 2017 4:00 pm May I say something a little discouraging...?
I was really really exited about DERGO (since I use blender files in my engine, I edit my materials in blender too)... but... now Blender 2.8 with Eevee is around the corner and I think efforts should be put in making Ogre look closer to Eevee and make a good exporter or blend loader. I think it would be better if you just do all your work in blender and then expect that in Ogre would look the same... or substance, quixel, etc they are all following the same standard.
I don't see it as discouraging because if Eevee allows for easy PBS setup that easily translates to Cycles, then I could finally have an easy setup for comparing as "ground truth". So that gets me more excited.
Besides, although Eevee definitely fills a hole better than Dergo (lack of real time high quality PBS preview in Blender), Dergo is still useful for interfacing with Ogre: Exporting meshes, materials, testing compositors, testing different shaders (eg. Toon).
Or for example to render stuff that Blender would normally be unable to (or at least at high quality), like Terra.

So while its usefulness diminishes (specially for users outside of Ogre community Dergo's), it's still very useful.
Hotshot5000
OGRE Contributor
OGRE Contributor
Posts: 226
Joined: Thu Oct 14, 2010 12:30 pm
x 56

Re: [2.1] Ogre 2.1 official release goals

Post by Hotshot5000 »

dark_sylinc wrote: Wed Nov 15, 2017 12:51 am
Something I'm curious to see is Ogre 2.2 + Android; even though it's WIP, the new texture manipulation code is much cleaner, to the point and should theoretically cause much fewer bugs with the drivers.
What are the (planned) additions/changes for 2.2? Is it (semi-)stable? I'm asking because in December I will have some free time to experiment and I'm thinking maybe I should make GLES3 work on the 2.2 branch if you say there could be fewer bugs with Android. I'm already behind in that GLES3 works with a 2.1 version from March 2017 so I'll need to become up to date with the 2.1 branch first, but while I'm there, maybe I can also do something for 2.2.

Also, on my analysis, I know there is some wishful thinking in it but what encourages me is that at the beginning of the year there were 45% GLES2 devices and now there are only 37%. And most new devices are GLES3.1 devices (Google seems to not measure GLES3.2 devices so I will assume they are part of the 3.1 measurements). I don't know about the driver quality but I don't think they will be worse than what we have.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [2.1] Ogre 2.1 official release goals

Post by dark_sylinc »

Hotshot5000 wrote: Wed Nov 15, 2017 11:55 am What are the (planned) additions/changes for 2.2? Is it (semi-)stable? I'm asking because in December I will have some free time to experiment and I'm thinking maybe I should make GLES3 work on the 2.2 branch if you say there could be fewer bugs with Android. I'm already behind in that GLES3 works with a 2.1 version from March 2017 so I'll need to become up to date with the 2.1 branch first, but while I'm there, maybe I can also do something for 2.2.
Semi-stable is probablythe right word for it.
I wonder how hard would be to make GL3+ be used for also GLES3 but with a couple ifdefs (so we can share common code more easily)

I'm compiling a cheat sheet on the changes, this is what I so far:
The following will be soon removed from our codebase:
  1. Texture
  2. HardwarePixelBuffer
  3. RenderTarget / RenderTexture / RenderWindow
The following are the equivalences:
  1. Texture -> TextureGpu
  2. Rendering: RenderTarget / RenderTexture / RenderWindow -> TextureGpu
  3. Writing to a texture:
    Old:
    1. Map a HardwarePixelBuffer (synchronous)
    New:
    1. Map a StagingTexture
    2. Upload from StagingTexture to TextureGpu (asynchronous)
  4. Reading from a texture:
    Old:
    1. Map a HardwarePixelBuffer (synchronous)
    New:
    1. Download to an AsyncTextureGpu. (asynchronous)
    2. Map the AsyncTextureGpu
Things to watch out for when porting to 2.2:
  1. Previously numMipmaps = 0, meant it only had the main mip. Now numMipmaps = 0 is impossible, since the main mip is also counted. This means you need to watch out for getNumMipmaps() vs getNumMipmaps() + 1; or similarly for( i=0; i<=numMipmaps; ++i ) needs to be changed to for( i=0; i<numMipmaps; ++i )
  2. TexturePtr is default initialized to 0 because it's a SharedPtr. TextureGpu is not, it's a raw pointer. This is also a common problem with arrays of textures i.e. TexturePtr myTextures[5];
  3. Compositor textures are non-msaa by default. Use msaa <number of samples> or msaa_auto. In Ogre 2.1 all compositor textures defaulted to being msaa
So that's basically the change. We collapsed Texture, RenderTarget & HardwarePixelBuffer into one (TextureGpu), and added StagingTexture and AsyncTextureGpu to upload / download data from/to these textures. TextureGpu cannot be mapped directly, there is no TextureGpu::map / unmap.
In GL lingo, StagingTexture and AsyncTextureGpu are just PBOs.

TextureGpu also incorporates internally the notion of being part of a pool (i.e. what HlmsTextureManager does), which means a TextureGpu created with TextureFlags::AuomaticBatching may be internally be created as a Texture2DArray, and be part of a slice (see TextureGpu::getTexturePool and getInternalSliceStart). Externally, Ogre acts as if TextureGpu is just a single texture, while internally it is handled as a slice to a Texture2DArray.

Another issue that was fixed is that the old texture system tend to give automipmapping to everything (which meant calling glGenerateMipmaps and waste memory and CPU cycles on the driver allocating temporary storage for mipmap generation) whereas the new system rarely gives automipmapping, and automipmapping requires setting the flag TextureFlags::RenderTexture (which makes explicit the performance penalty).
Ogre 2.2 does have HW mipmap generation, but the default implementation creates a temporary texture with RenderTexture and Automipmap flags, and then copies the mipmaps to the actual texture, then destroys the temporary texture.

Something internally for porting:
Normal users don't see this, but to render you need to setup a RenderPassDescriptor. RenderPassDescriptor were designed drawing inspiration from Metal, which fits mobile design very well.
Basically rendering gets encapsulated into <load> -> <render> -> <store> semantics. Load semantic can be set to dont_care, clear, and load.
Clear resets the TBDR's cache to a single colour (i.e. it's just a glClear). Dont_care loads nothing. Whatever is in RAM. Load loads the data from RAM.
Similarly store means we store to RAM, dont_care means we discard the results (i.e. depth and stencil buffers contents usually can be discarded), and then there's Resolve and StoreAndMultisampleResolve.
This means we support "dont_care" load and store semantics, which means we can call glInvalidateFramebuffer so tilers can avoid flushing their caches to RAM.
When store semantic is set to "Resolve" (instead of StoreAndMultisampleResolve) we call glBlitFramebuffer to resolve the MSAA buffer, and then can call glInvalidateFramebuffer on the MSAA texture so the tiler doesn't flush the cache of the MSAA surface to RAM, and only writes the resolved texture. This needs testing though. Considering Android driver quality, I wouldn't be surprised if the driver gets confused and writes nothing instead.
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: [2.1] Ogre 2.1 official release goals

Post by xrgo »

dark_sylinc wrote: Wed Nov 15, 2017 4:20 pm Semi-stable is probablythe right word for it.
Interesting! mmm...
I would like to start integrating 2.2 in to my engine, I don't mind if features/api changes in the future, I do mind if its going to crash a lot, do you recommend me to start integrating 2.2?
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [2.1] Ogre 2.1 official release goals

Post by dark_sylinc »

xrgo wrote: Wed Nov 15, 2017 7:07 pm
dark_sylinc wrote: Wed Nov 15, 2017 4:20 pm Semi-stable is probablythe right word for it.
Interesting! mmm...
I would like to start integrating 2.2 in to my engine, I don't mind if features/api changes in the future, I do mind if its going to crash a lot, do you recommend me to start integrating 2.2?
Yes. The main interfaces aren't going to be changing much now.

Do you see it feasible to make GLES3 on top of the GL3+ renderer?
For example your GLES3TexBufferPacked has already been ported to GL3+ by another user, so that the renderer works on macOS.
Hotshot5000
OGRE Contributor
OGRE Contributor
Posts: 226
Joined: Thu Oct 14, 2010 12:30 pm
x 56

Re: [2.1] Ogre 2.1 official release goals

Post by Hotshot5000 »

The question is adressed to xrgo but I thought I might chime in and say that a lot of things are common between GL3Plus and GLES3. So much that I think there should be something like GL3Common with subdomains GL3Plus and GLES3. When I'll have some time I could do that but I can't give any estimates. Maintenance would be much easier that way. Or maybe have one project with #ifdefs for GL3 and GLES3 code like dark_sylinc suggested.
Post Reply