pouët.net

What about my home pc (linux)? You're just a meanie!

> yeah writing memory you didn't allocate, that should just be tolerated.
> (wtf are you saying?)

*attempt* to write. The API can stop you by a crash or ignoring the call. You would want to fix this in either case, I just find it less annoying if I don't get that horrible message box with the "bing" sound.

A little thing, I know it sounds all too weird but the whole thing annoyed me alot in the past.

sorry, my pc's minority is shared by ~30% of the market, yours is more like 3%.. thats why :)

navis: maybe it should have an option: "do you want to shoot yourself in the foot or the arse?" :)

ok ok I've just had a hard time cycling through snow and ice only to be greeted with a crash bug.

I agree with what you all say about wrappers to emulate the "immediate" mode and crashes with possibility of debugging. Maybe I should try that again in the future (likewise I was quite negative with the xbox360 beforehand, but after a while it was alright).

I guess it is all down to personal preferences and habits, and you know the saying: you can't teach an old dog new tricks... :-/

smash, probably significantly less than 3%... :)

so you're a fan of http://msdn.microsoft.com/en-us/library/aa366716(VS.85).aspx :)

* I'm blinded *

ask raymond chen about it

"And that's a GUARANTEE!" *

* Warning - not a guarantee.

exceptions like read/write violations are serious offenses/programmer error and in no way should a program function beyond that point, at least not beyond a solid crashhandler if it's a pc/desktop computer app we're talking about

at least thats what i picked up over the years :)

(and sure for things that are operative and have to be stable (avionics, banking stuff et cetera), graceful handling of exceptions is due, but i think we can all stick to the context at hand here for now)

About managing the OpenGL states: using shaders you just have like 4 or 5 states. The rest is ignored. And states on modern hardware are probably implemented in software. Just set whatever you need to set before rendering. It doesn't have to be complicated and it probably won't get any slower.

I don't disagree; how wants to mess up with system memory.

I was referring to graphics operations that, if fail, should not bring a catastrophic failure (for example: shader not working for whatever reason, incompatibility, wrong tokens. Doing a glBlendFunc in between a glBegin/end., stuff like that).

As a matter of fact I think opengl *will* crash on you if you try to overrun a buffer with vertex arrays and such. I haven't managed to crash "immediate" mode in opengl.

i'm not entirely sure about that -- of course setting a render state or binding a shader that's off the rocker shouldnt crash an application but you should be able to handle that. or ideally, have a fair way of detecting what can be expected to work and not work on beforehand and go by that. i feel that, even for pc apps, after a certain point in the hierarchy stuff should just work (and if not, that's reason to halt the app as a whole). there are ways to assert that. but perhaps that view largely originates from coding console games the last 6 years.

Navis: DirectX doesn't crash if your shader fails to compile. Trying to use a COM-pointer that doesn't point to a COM-object as one does. This is your fault, and not the API. Perhaps you prefer the OpenGL "opaque handles" better, but us driver developer does not. Looking up hash-maps to validate pointers all the time is a hassle. Combine this with list-sharing and multi-threading, and have a fun time.

Well, on my side i don't see the point as well to let down opengl. There are still few things that i like in it over direct3d..

to name,
- GLSL has a preprocessor. it's all done. yay <3
- GLSL has binding for classic fixed functions variables. This is absolutelly <3 instead of having to create 3000 uniforms when you work out your lighting..

furthemore, some of the new extensions that were introduced with opengl 3 are actually looking really <3.

- GL_EXT_direct_state_access is really going to speed up a LOT opengl calls by supressing most redundant calls to change bindings. opengl calls have never been much of an issue like in directX as they've always been faster, but, well, extra speed is never useless.
- GL_EXT_draw_instanced adds geometry instancing, despite this feature has been looked down upon a lot as opengl calls are much cheaper than d3d so removing calls has never been so much of an issue before.

Plus few good surprises, like, all my opengl code works just fine on vista without any test or modification...

well all in all, i stay in the opengl ship.. for home code at least. <3

ehm, "validate handles", not pointers :)

nystep: HLSL also has a preprocessor.

mm 'k, yet you don't deny opengl superiority on other points ;)

wat? troll? me..? xD

I would really love to see opengl crash when I do an invalid operation. My development time would be much faster, and my code cleaner (not need to put one assume(!glGetError()) every 4 lines of code).

Same for shaders, what a dream to see gl allowing me to precompile or preparse glsl shaders; although there are workarounds to fight this annoying issue.

which workarounds?

that is not a plus, that kind of crap is exactly what in the end will clutter an API and hinder driver development because in a few years they're still going to have to find a way to work in pure legacy support.

come on, how hard is it to set a few variables; the whole idea is that you develop your own pipeline now. if you don't want that, just use the f*cking legacy pipe. ogl still supports that right?



hlsl has that as well, duh. or are you talking about something else?



d3d has instancing.

as for the direct state access -- issues like these are deferred to the driver level with d3d, which makes more sense as every piece of rendering hardware has different priorities in regard to commandbuffer building. that extension, like so many others, is a factual piece of evidence that the api design doesnt have its priorities straight and is constantly hindered by backwards compatibility.

iq, I do something like :

#ifdef DEBUG
#define GL_CHECK(x) { x; assert(glGetError()==GL_NO_ERROR); }
#else
#define GL_CHECK(x) x;
#endif
...
GL_CHECK(glSomething());

Not exactly elegant but quite helpful sometimes...