Vector graphics

[Lyberta]

Deleted.

[fluffrabbit]

Regarding the above quotes:

A software renderer can do a lot more than a PS1. The PS1 has no Z-buffer, thus it's exceedingly difficult to make something like a first-person shooter on the PS1 without subdividing all the polygons. I tried a similar HTML5 canvas rendering engine a long time ago and all I could come up with was Tandy-era garbage. Mesa has a GL 3.3 software renderer with more features than WebGL 2 and most phones, and it's fast.

I think drummyfish's software renderer is interesting because the Allegro 4 API isn't namespaced (ugh) and modern Mesa is too bulky to port to things like DOS, so it would fill the niche for a public domain embedded 3D renderer that focuses more on quality than irrelevant stuff like GL compatibility.

"vector-based textures" - I think onpon4 means vertex colors. That technique is used in converting point cloud data to polygons, and it was used on the PS1 at a lower density because the console lacked texture filtering, so it could be used for smooth skies and stuff. glTF does not support vertex colors because they're physically incorrect.

OK, this is more of a technical thread. I'm working on the 2D engine and pixel art is not something I want for my games. Realistic HD textures also don't make much sense in 2D. So this basically leaves vector graphics. So, what are the technical details of such implementation?

Well, out of the all vector graphics formats the SVG seems to be the only popular one. And it comes with its own animations. Has anyone worked with this? You can make SVG files in text editor or in Inkscape. So, does anyone use SVG for graphics in their games? What about models? It looks like Godot has skeletal animation even in 2D. What format to use? What about glTF for 2D?

I have an ongoing animation project that uses SVG to an extent, and I have even written a glTF loader for games, but I'm still not very knowledgeable about 2D vector graphics. One thing I do know is that SVG is too slow for realtime display because it antialiases each layer individually rather than the composite graphic. Because it's an editing format from the '90s. SDL_image loads non-animated SVGs as bitmaps, and that is probably the easiest way to use 2D vector graphics if you are using C/C++.

glTF can do a lot of things and is of course fast to render because it's just polygons, but I don't know of an editing tool that uses glTF as a 2D format. One thing you could do is model everything in 3D and render with orthographic/parallel projection and an outline effect. [1] [2]

If your engine only supports OBJ models, Blender can export animations as a series of them for use in a similar way to frames of sprites. If you're using a 3D format, textures are a must. The future is PBR and POM and volumetric raytracing where textures might even be considered outdated, but right now you can use low-res 32px or 64px textures that look very basic and oldschool.

[Julius]

I think there is interesting stuff happening with vertex shaded but high resolution 3d art in the mobile VR space.

[fluffrabbit]

I think there is interesting stuff happening with vertex shaded but high resolution 3d art in the mobile VR space.

A few years ago flat shading was all the rage in that space. Do you have a screenshot to illustrate what you mean?

[drummyfish]

If you're looking for ready-to-use solutions, then I believe using 2D vector graphics, e.g. SVG, is handled the same as fonts -- they're vector, but for real-time rendering they're rasterized at run-time, in whatever resolution you need, because GPUs are simply optimized for bitmaps. So you simply want a SVG rasterizer (I think e.g. Cairo?), plus a normal engine.

3D is vector by default, but it's combined with texture mapping, which typically utilizes raster textures -- and this is where I've seen onpon4's idea of maybe directly using vector textures as interesting, but more as a research topic, I haven't seen anyone do it... This would be for someone trying to create a novel engine, with a whole new rendering 3D pipeline, which could later be accelerated on GPU etc., but that would be a big project. In the old days every game created its own unique engine and they tried out different techniques like raycasting, splatting, voxels, BSP trees etc. I'd like to see some of this spirit again.

[fluffrabbit]

I'm going to get really really OT now since I'm purely talking about 3D. Death drives evolution. Nothing so profound has happened to 3D since original Half-Life. A 286 can't handle much, and the 68k and PowerPC processors of the time which could handle a bit more were not as popular with the home gaming market. I was a baby back then, but I grew into a lot of pre-rendered and flat-shaded (IMHO) crap on the Mac which was still twice as good-looking as the stuff on DOS. LHX Attack Chopper was the standard back then, so Doom was made out of desperation to make some 3D that doesn't make your eyes bleed. They played around with voxels for a while in the Build engine, but Half-Life set developers straight for a couple decades.

[drummyfish]

but Half-Life set developers straight for a couple decades.

Too straight, to the point of no other option not only in the mainstream, but even the indies. The fixed-pipeline GPUs have established this and even though nowadays we have programmable GPUs and enough power for nice SW renderers, the inertia of the original paradigm is there, the GPU hype is all over gaming (even libre), it has gotten too far, too much money have been invested in this specialization. The engine itself dictates a lot of constraints and sets directions, so a different approach can lead to not only a very unique aesthetics, but also gameplay. Still today there are people who try new things, though these don't usually grow beyond the experimental stage, which is shame. E.g. this:

https://hooktube.com/watch?v=0pmSPlYHxoY

I also like how Marble Marcher experiments with fractals, and even made it to a nice small playable game.

[fluffrabbit]

That is really something else. Makes me question the nature of physical space. You certainly can't do that with CryEngine. Still, experimental 3D is hard while textbook polygon 3D is almost as easy as 2D, as you said due to incumbent techniques. I don't know if Lyberta would want to do anything like that for a 2D vector art game, but it would certainly make it more interesting if there were a dimensional wormhole in the midddle of the otherwise standard flat world. Now I'm trying to imagine how to incorporate this into a 3D polygon system.

[Lyberta]

Deleted.

[fluffrabbit]

One thing I do know is that SVG is too slow for realtime display because it antialiases each layer individually rather than the composite graphic.

Surely we can write our own rasterizing code.

Very ambitious. SVG is built on top of XML, has a separate language to control its animations, and supports paths and other shapes which aren't a 1:1 match with OpenGL triangles. That's layers of complexity, while writing a 3D model loader is doable by a single person within a week (animations notwithstanding). There might be code out there to triangulate SVG, so that would be a start.

SDL_image loads non-animated SVGs as bitmaps, and that is probably the easiest way to use 2D vector graphics if you are using C/C++.

But that means camera zoom would reveal pixels unless I rasterize each frame.

Textures with crazy high resolutions and trilinear filtering for smooth scaling is doable on phones, web browsers, you name it. GLES3 guarantees 4K textures per the standard.

I plan to use the proposed 2D graphics TS which uses Cairo on Linux.

Blasphemy. If that becomes standard C++, the message is that there is one specific way that 2D graphics should be rendered, which people are sure to disagree on and possibly regret. Look no further than all the failures of JavaScript.

They played around with voxels for a while in the Build engine, but Half-Life set developers straight for a couple decades.

Well, I would say Far Cry proved that you could do much better than HL. I remember around 2008 I was mapping for Team Fortress 2 and "enjoying" waiting ~40 minutes for my map to compile and then I've seen the video of Crysis map editor that did everything and much better in real time. That was a big existential crisis (oh wow, I didn't plan that pun) for me.

I've had similar crysises regarding the time I dumped into DarkBASIC programming. But one thing all these systems have in common is triangles, which has been the religion of 3D graphics for an entire human generation.

[drummyfish]

If your engine only supports OBJ models, Blender can export animations as a series of them for use in a similar way to frames of sprites. If you're using a 3D format, textures are a must. The future is PBR and POM and volumetric raytracing where textures might even be considered outdated, but right now you can use low-res 32px or 64px textures that look very basic and oldschool.

I don't have any model support right now and I want smooth animations so rendering them as preset frames doesn't suit my goals.

A series of OBJ frames does produce smooth animation, you interpolate between the frames, so they're more like keyframes. I often even preferred it to bones animation as it's much simpler and compatible (bones are good when you start attaching things to things or doing things like ragdoll physics, but for simple animations they're overkill). Here is a video of this in my first 3D engine, it's only three OBJ frames I think (sorry, I was still using Windows back then).

Surely we can write our own rasterizing code.

Yep, it's good to keep in mind vector is not just SVG. You can also take SVG and modify it... write your own renderer of only a subset of SVG if that's all you need, and you can still edit that with Inkscape -- I was even considering implementing a SVG subset renderer for Arduboy (console with monochrome 128x64 display and 2.5 KB of RAM). Or you can think of expanding it to other mathematical functions than basic geometric primitives, where you'll start getting into procedural textures -- It all depends on the usecase. I remember John Carmack once called procedural generation just a "shitty compression", but I don't fully agree with it -- e.g. here is a pretty impressive completely procgen 3D FPS in just 96 KB.

[dulsi]

Does vector format really solve the problem? While you it can still stay sharp when you are close to it, I'm not sure you are going to get something that looks complex like tree bark without a very complex graphic. (I'm not an artist and have not played much with svg so I could be uninformed.

[Lyberta]

Deleted.

[fluffrabbit]

Very ambitious. SVG is built on top of XML, has a separate language to control its animations, and supports paths and other shapes which aren't a 1:1 match with OpenGL triangles. That's layers of complexity, while writing a 3D model loader is doable by a single person within a week (animations notwithstanding). There might be code out there to triangulate SVG, so that would be a start.

That library I linked has SVG demo. It looks like it uses RapidXML and SVG++ for most of the work. I know, not quite the DIY way but seems to be possible.

I'll have to check that out.

Textures with crazy high resolutions and trilinear filtering for smooth scaling is doable on phones, web browsers, you name it. GLES3 guarantees 4K textures per the standard.

But why would I have a huge textures instead of having a bit of XML and drawing it instead?

It's a tradeoff between graphics memory and performance. If the library rasterizes by doing a memset every line, layer by layer, it's not going to be as fast as an OpenGL texture lookup at every pixel. If it turns everything into an optimized intermediate format like a triangle mesh, it could be faster than the texture route, but textures are still fast. GPUs are built around textures; that's their main advantage over software rendering.

Blasphemy. If that becomes standard C++, the message is that there is one specific way that 2D graphics should be rendered

Not really. It means that there will be a default way to render 2D and 90% of people wouldn't need to hunt down some 3rd party library. There is also an audio proposal too.

To hell with that 90% of people. 90% of people should just be using PyGame or something anyways. I seriously doubt this is going to improve software quality. Rather, it's going to turn C++ into the new Java and scare more conservative programmers back to C, losing a lot of C++'s core advantages like being able to copy large chunks of data as function parameters.

A series of OBJ frames does produce smooth animation, you interpolate between the frames, so they're more like keyframes.

Does it store the curve parameters for interpolation?

No, you interpolate between the frames to fudge a higher framerate from whatever the exported framerate was. vertC = lerp( vertA, vertB, f ) (Or you can use a different interpolation method, but that data typically isn't in the OBJ files; OBJ isn't an animation format.) It's called shapekey animation, but Wikipedia uses some nonsense Quake term for it. It's pretty ubiquitous, you just live with whatever precision you get.

Does vector format really solve the problem? While you it can still stay sharp when you are close to it, I'm not sure you are going to get something that looks complex like tree bark without a very complex graphic. (I'm not an artist and have not played much with svg so I could be uninformed.

Well, one very important problem is not being able to play a lot of games on high PPI monitor because they've chosen raster graphics and only provided default resolution textures. For example, Hedgewars, I have to mostly blindly select weapons based on memory and when I zoom in so I can see the map, I see pixelated mess.

Pixel art is an aesthetic choice and III/AA games do their scaling properly; it's only the nerd games with the pre-2010 mindset that unwittingly sabotage their user experience.

[Lyberta]

Deleted.

[drummyfish]

Does it store the curve parameters for interpolation?

Of course not, but with enough frames in appropriate places you can approximate any curve close enough, and you can still use something better than lerp for the inbetween frames if you really want to. It takes more memory, but is much less complex than armatures and arbitrary curves... as with anything, it's a tradeoff. The point is armatures are often favored in situations when they are unnecessarily complex and complicated, bring in additional dependencies and so on, only because it's the only thing people know. What I am talking about here is a kind of countercomplex, suckless philosophy.

[Lyberta]

Deleted.

[drummyfish]

Well, I want to save on hitboxes so I wanted collision detection to use actual models and I plan on continuous collision detection which require to define everything using math formulas. And considering that consumer monitors right now go up to 240 Hz. Storing that much of animation seems impractical.

I see... what exactly do you mean by "save on hitboxes"? You will always have to use hitboxes or similar bounding volumes to accelerate collision detection.

Using the actual visual model for collision detection is extremely expensive though -- the triangles are mathematically defined too, and it doesn't matter in what way they're animated in this case, there's simply too many of them to check -- so it's almost never done this way. Do you really need so precise collisions? If it's a COD type of shooter where it really depends on where you hit, a simplified physical shape -- consisting of a few primitives like capsules for arms and spheres for a head -- could be good and fast enough. In this case armature would be appropriate, because you have to stick these capsules to something. Still, if it doesn't matter that much, I'd go for hitboxes and simple animation -- you can still roughly estimate what part of body is hit even with a hitbox. AFAIK for continuous collision detection it doesn't matter what kind of animation you use -- it still happens in discrete steps, it just checks the whole continuous path for a collision, not just one specific point.

Also 240 Hz doesn't mean you have to run on 240 FPS, that would be crazy. Even with very high FPS game the animations will typically be lower FPS -- like 60 -- even if you have a complex animation system. Even for smooth animation I'd save e.g. just every 10th frame, so it's not that much... of course depending on the complexity of the model and length of animation. Just to make it clear you don't have to save 240 OBJ frames per second. If the size of the animation is really a problem, you can try some very simple compression (instead of saving vertex position, save the difference against the previous position instead, with a code that's smaller for smaller differences).

[fluffrabbit]

It's a tradeoff between graphics memory and performance. If the library rasterizes by doing a memset every line, layer by layer, it's not going to be as fast as an OpenGL texture lookup at every pixel. If it turns everything into an optimized intermediate format like a triangle mesh, it could be faster than the texture route, but textures are still fast. GPUs are built around textures; that's their main advantage over software rendering.

So again, depends on the library. And considering how important 2d rendering is nowadays, I'm pretty sure people have thought about it. Like on Windows there are Direct2D and Direct3D. I'm pretty sure they both use GPU efficiently.

But we're talking about 2D vector graphics. That's mainly an Adobe thing. Games by and large don't use it, so SDL, Direct2D, etc. efficiently render textures. (Well, SDL isn't especially efficient at that, but it's still fast enough.)

90% of people should just be using PyGame or something anyways.

In my experience, language with dynamic typing are impossible to program with. I have to write Python scripts for my C++ libraries because there is no other sane package manager for C++ now than Conan and it forces Python. Pythons sucks extremely. I also messed with Lua trying to write actual code. It's insane. 99% of the code is just checking that your arguments are valid.

Python is a love-it-or-hate-it thing. Lua just sucks. Indexing arrays from 1 is bad news. You may be interested in Lobster. It's like statically typed Python with built-in 3D functionality.

I seriously doubt this is going to improve software quality.

It is because it is using idiomatic C++ unlike most other libraries that are basically C.

The library probably works, and SFML too is a fairly complete system for C++ with similar functionality. The problem is in trying to make these things part of the STL. I don't think that would be a good idea.

Rather, it's going to turn C++ into the new Java and scare more conservative programmers back to C, losing a lot of C++'s core advantages like being able to copy large chunks of data as function parameters.

Eh? How is giving developer better tools would scare them? It doesn't add garbage collection, it doesn't add virtual machine and all that crap. It keeps C++ C++.

It's an additional tool, not a better tool. It reminds me of the failure of Java3D and other various libraries that came packed with Java but that people didn't end up using. Then Java went away because of all the bloat, security issues, and gaps in low-level functionality. Even if C++ stays the same language, this API would lower the barrier to entry for low-end software and GUI apps while adding nothing that I myself would use. This would be one more large piece of software that would be required for a complete C++ implementation.

I like C++ for what its syntax can do, not for what the STL can do outside of strings and vectors. I use third-party libraries for more advanced stuff because they're better. But you communists seem to like handing control to authority figures rather than solving problems on your own. And yes, I will throw away C++ and turn to drink if this makes it into the standard.

No, you interpolate between the frames to fudge a higher framerate from whatever the exported framerate was. vertC = lerp( vertA, vertB, f ) (Or you can use a different interpolation method, but that data typically isn't in the OBJ files; OBJ isn't an animation format.) It's called shapekey animation, but Wikipedia uses some nonsense Quake term for it. It's pretty ubiquitous, you just live with whatever precision you get.

Well, I'd rather use something with proper animation baked in.

I would too, which is why I'm trying to get my glTF loader in ship shape. Not a big fan of OBJ's limitations, not a fan of all the parsing bugs it's giving me that are blocking my game from getting finished, not a fan of the Dungeon Keeper style of animations, but I guess I'll use it if I have to.

Just to make it clear you don't have to save 240 OBJ frames per second.

Yes, but anything lower than 60 FPS absolutely requires interpolation or you will see stuttering. I have yet to find a structurally clean way to interpolate meshes in the vertex shader, so you would be interpolating the vertices in C/C++ and updating the mesh at 60 FPS or whatever with glBindVertexArray( vao ) then glBindBuffer( GL_ARRAY_BUFFER, vbo ) then glBufferData( GL_ARRAY_BUFFER, ... ) then glBindBuffer( GL_ELEMENT_ARRAY_BUFFER, ibo ) then glBufferData( GL_ELEMENT_ARRAY_BUFFER, ... ). I can't think of a better way if you aren't using an animated model format.

[drummyfish]

I have yet to find a structurally clean way to interpolate meshes in the vertex shader, so you would be interpolating the vertices in C/C++ and updating the mesh at 60 FPS

Definitely should be done in vertex shader. It's been a long time since I've been involved with OpenGL, but can't you just update the vertex buffer e.g. at each keyframe? Send 2 position coordinates to each vertex and then only update the interpolation parameter. I know I've done it this way some time in the past. Maybe that's what you call not structurally clean?

[fluffrabbit]

I have yet to find a structurally clean way to interpolate meshes in the vertex shader, so you would be interpolating the vertices in C/C++ and updating the mesh at 60 FPS

Definitely should be done in vertex shader. It's been a long time since I've been involved with OpenGL, but can't you just update the vertex buffer e.g. at each keyframe? Send 2 position coordinates to each vertex and then only update the interpolation parameter. I know I've done it this way some time in the past. Maybe that's what you call not structurally clean?

That may make sense. The reasons I have shied away from that technique are:

* You aren't using an attribute layout that matches a file format. (Arbitrary I know, but what of the ancient Greek harmony of nature? I've used a lot uglier code in the past, but I'm aiming for perfection.)
* You're sending twice as much data to the GL server, and that bridge is the slowest part of the pipeline. If you're using a GPU, you save a lot of lerps on the CPU, and GPUs have lerp circuits for extra speed, but with the overhead of sending more data in a frame I dunno.

[Lyberta]

Deleted.

[fluffrabbit]

But we're talking about 2D vector graphics. That's mainly an Adobe thing. Games by and large don't use it, so SDL, Direct2D, etc. efficiently render textures. (Well, SDL isn't especially efficient at that, but it's still fast enough.)

Well I'm going to use them. And my primitives are shapes, whether consisting of line segments are curves, and filling them with something. That's not how 3d usually works. I've heard that NURBS is the implementation of true curves in 3D but only seen it in modelling software.

That's tricky, though I don't mean to discourage you from the aesthetic.

The more general (non-editor-software) version of NURBS is tessellation shaders, an OpenGL 4/DirectX 11 feature which is not present in WebGL and is not yet ubiquitous on mobile devices. I understand the mentality of not caring how things work and just wanting them to work, but as someone who has been doing OpenGL programming for a few years I distrust a thing for realtime games that I have experienced severe slowness with in editing software and which doesn't match my knowledge of OpenGL's way of rendering. I'd be willing to bet that you can render at most 25% the number of vector sprites as you can texture sprites unless the vector sprites are (possibly automatically) baked as textures or a batch of polygons.

The library probably works, and SFML too is a fairly complete system for C++ with similar functionality. The problem is in trying to make these things part of the STL. I don't think that would be a good idea.

As someone who touched it, it doesn't look idiomatic at all. It has constructors that do nothing. I'm also pretty sure it uses error codes instead of exceptions.

As someone who has only used SFML as a thin wrapper for basic OpenGL stuff, I haven't seen much of the nasty side. However, I do know that there is a nasty side, and that's what makes choice in a diverse array of competing libraries such a great thing. Don't trust one organization to get it right.

It's an additional tool, not a better tool. It reminds me of the failure of Java3D and other various libraries that came packed with Java but that people didn't end up using.

But a lot of people use Swing and it has much more features than a 2D library.

A lot of people also say that both Swing and Java are bad things to use. Swing in particular looks dated and non-native. wxWidgets is the thing to use if you want a nice GUI.

Even if C++ stays the same language, this API would lower the barrier to entry for low-end software and GUI apps

That's the point.

When this software does hit the fan I'll grab my popcorn.

I like C++ for what its syntax can do, not for what the STL can do outside of strings and vectors. I use third-party libraries for more advanced stuff because they're better. But you communists seem to like handing control to authority figures rather than solving problems on your own. And yes, I will throw away C++ and turn to drink if this makes it into the standard.

In my experience there are almost no 3rd party libraries with package manager support. Also, did you know that ISO is run by volunteers? I'm trying to participate and put some of my code into the standard. What, now I'm communist and totalitarian dictator?

So your solution is to install the libs on every computer in the world? Come on. Software changes over time, and old crud should get thrown out, ideally being replaced by unrelated third-party software written by people with a head on their shoulders. The C++ standards committee is a mess, just like Mozilla and Russia. Better to bring your own libraries, get them from the source, and don't use too many of them.

Congrats on having software you feel is worthy of the standard. That doesn't make you a dictator. You're simply participating in a collective dictatorship.

[Lyberta]

Deleted.

[fluffrabbit]

but as someone who has been doing OpenGL programming for a few years I distrust a thing for realtime games that I have experienced severe slowness with in editing software and which doesn't match my knowledge of OpenGL's way of rendering.

Well, apparently OpenGL is dead and Vulkan is all the rage now. I mean OpenGL is just one of the possible abstraction layers of how hardware actually works. And from what I understand is it was designed for single threaded rendering and CPUs. If I ever get to 3D, I will most likely jump straight to Vulkan.

That's a good idea, but if you want your game to be compatible with the broader Linux community at this point in time, the API underneath the API you use will likely be OpenGL. GL uses multiple simultaneous cores of a single GPU, just not on multiple simultaneous GPUs, which is what Vulkan and DirectX 12 offer.

Not that it matters anymore, but the design of OpenGL completely changed after Khronos acquired it from Silicon Graphics, which is what the term "modern OpenGL" refers to. Oldschool OpenGL 1.1 "crosses the bridge" (sends direct instructions to the GPU) for each individual triangle that gets rendered, so it's actually slower than direct software rasterization on recent computers. The API is not nearly that bad anymore, in fact OpenGL 3.3 Core Profile/GLES 3.0/WebGL 2 are effectively a single friendly API that outdoes DirectX 10 and has a reasonable learning curve if you have a couple years to kill, though of course you should definitely focus on Vulkan instead at this point in time.

So your solution is to install the libs on every computer in the world?

My solution is to expose what is already installed. Windows and macOS have native graphics APIs baked into them. Linux desktops have either X or Wayland. It's already there, just not exposed in a good way.

Everything is already there. GUIs, web browsing, audio, mouse and keyboard input, but these are fundamentally different operating systems, so the intermediate layer is effectively a platform, and the larger that platform grows the harder it becomes to use on new and/or resource-constrained systems, just like Java. I hate Java, and you should too if you have any sense.

Come on. Software changes over time, and old crud should get thrown out, ideally being replaced by unrelated third-party software written by people with a head on their shoulders. The C++ standards committee is a mess, just like Mozilla and Russia. Better to bring your own libraries, get them from the source, and don't use too many of them.

ISO standardized interface and not the implementation. 2D graphics and audio have been on computers for several decades and all share common traits. It's the job of ISO to expose those traits.

It is the job of the C++ standards committee to standardize what constitues a complete C++ implementation. These new proposals to me border on abuse of power. If I managed a compiler suite, I would say no graphics, no audio, no networking, none of that operating system BS because this is a low-level programming language with high-level syntax, and my goshdarn C++ may not be perfect but it's a heck of a lot cleaner than what these jokers want to shove into it.

Congrats on having software you feel is worthy of the standard. That doesn't make you a dictator. You're simply participating in a collective dictatorship.

For example, C++ doesn't have byte-based IO, so I wrote a serialization library to fix this. Now that the language itself has evolved so I could remove most of the non-portable bits I felt that it is a good time to propose it for standardization. The thing is, standard library gets a privilege of knowing the platform. All other code stays in much less privileged position because a lot of stuff is implementation defined. As soon as you assume specific behavior, your code becomes non-portable.

That's a good point about portability concerns. That is a problem Java tried and failed to solve. Why? Because if you look closely enough you see that the little holes add up to a big blanket you need to throw over them, so the bloat of for instance SDL is a blood sacrifice that the programmer makes in exchange for his or her code being portable, and SDL is its own portable platform not unlike Java. It all depends on how you want to use C++ I guess. I have my own idealized programming language in mind, but it may never see the light of day because everyone just wants more and more platform features and doesn't seem to care about syntax. When C++ or D gets it most of the way right, they have to pile all that platform BS on top of it, and I just want a clean programming language.

Maybe I'm crazy. Maybe abstracted platforms are a universally beneficial thing. One thing they're not is nostalgic, at least not the kind of nostalgia I want. Java, .NET, Microsoft Visual C++ Runtime, no thanks.