A bit of my personal history, experimenting in 3D game design.

I was wide-eyed and curious. And much before the year 2000, I only owned Windows-based computers, purchased most of my software for money, and also purchased a license of 3D Game Studio, some version of which is still being sold today. The version that I purchased well before 2000 was using the ‘A4′ game engine, where all the 3DGS versions have a game engine specified by the latter ‘A’ and a number.

That version of 3DGS was based on DirectX 7 because Microsoft owns and uses DirectX, and DirectX 7 still had as one of its capabilities to switch back into software-mode, even though it was perhaps one of the earliest APIs that offered hardware-rendering, provided that is, that the host machine had a graphics card capable of hardware-rendering.

I created a simplistic game using that engine, which had no real title, but which I simply referred to as my ‘Defeat The Guard Game’. And in so doing I learned a lot.

The API which is referred to as OpenGL, offers what DirectX versions offer. But because Microsoft has the primary say in how the graphics hardware is to be designed, OpenGL versions are frequently just catching up to what the latest DirectX versions have to offer. There is a loose correspondence in version numbers.

Shortly after the year 2000, I upgraded to a 3D Game Studio version with their ‘A6′ game engine. This was a game engine based on DirectX 9.0c, which was also standard with Windows XP, which no longer offered any possibility of software rendering, but which gave the customers of this software product their first opportunity to program shaders. And because I was playing with the ‘A6′ game engine for a long time, in addition owning a PC that ran Windows XP for a long time, the capabilities of DirectX 9.0c became etched in my mind. However, as fate would have it, I never actually created anything significant with this game engine version – only snippets of code designed to test various capabilities.

Continue reading A bit of my personal history, experimenting in 3D game design.

A fact about how software-rendering is managed in practice, today.

People of my generation – and I’m over 50 years old as I’m writing this – first learned about CGI – computer-simulated images – in the form of ‘ray-tracing’. What my contemporaries are slow to find out is that meanwhile, an important additional form of CGI has come into existence, which is referred to as ‘raster-based rendering’.

Ray-tracing has as advantage over raster-based rendering, better optical accuracy, which leads to photo-realism. Ray-tracing therefore still gets used a lot, especially in Hollywood-originated CGI for Movies, etc.. But ray-tracing still has a big drawback, which is, that it’s slow to compute. Typically, ray-tracing cannot be done in real-time, needs to be performed on a farm of computers, and typically, an hour of CPU-time may be needed, to render a sequence which might play for 10 seconds.

But, in order for consumers to be able to play 3D games, the CGI needs to be in real-time, for which reason the other type of rendering was invented in the 1990s, and this form of rendering is carried out by the graphics hardware, in real-time.

What this dichotomy has led to, is model- and scene-editors such as “Blender”, which allow complex editing of 3D content, often with the purpose that the content eventually be rendered by arbitrary, external methods, that include software-based, ray tracing. But such editing applications still themselves possess an Editing Preview window / rectangle, in which their power-users can see the technical details of what they’re editing, in real-time. And those editing preview windows are then hardware-rendered, using raster-based methods, instead of the final result being rendered using raster-based methods.

Continue reading A fact about how software-rendering is managed in practice, today.

About the Frame-Rate of Hardware-Accelerated Animations.

One of the subjects which I’ve posted about before, is that in the case of typical hardware-accelerated animations, the frame-rate, which some people just know as ‘the FPS of the animation’, is actually lower than the refresh-rate of the monitor.

Well, if the user is running Plasma 5 as his desktop-manager – which is Linux-based – then he can open ‘System Settings -> Desktop Behaviour -> Desktop Effects’, and he will see a list of available compositing effects, that would all be hardware-accelerated, and under the section of ‘Tools’, there is an effect named ‘Show FPS’. Enabling that effect, and then clicking on ‘Apply’, will cause a piece of OSD information to display, that actually shows the frame-rate. The user will notice that it does not equal the refresh rate of his monitor.

But there is a catch to this. Often, the rendering software will place an upper limit on the frame-rate. Frame-rates actually higher than the refresh rate of the display device accomplish no useful purpose, and there used to be a simple, command-line test which Linux users could run, which was called ‘glxgears’. This would display a very simple animation, of a red, a green and a blue gear, rotating smoothly. In very early versions of this test-program, a frame-rate of something unreasonable, such as 2000 or maybe even 5000 FPS might result, which simply represents a waste of GPU power. The gears would still rotate at the same, correct apparent speed, but each frame-cycle would be fewer than 1 millisecond apart on average. Therefore, more-recent versions of this test-program will cap the frame-rate at the refresh rate of the monitor, and the gears will display as rotating at the same, smooth speed.

Dirk

 

OGRE 1.11.5 Working on ‘Phosphene’

One of the open-source software projects which has often fascinated me, is called OGRE, which stands for Open-Source Graphics Rendering Engine. It’s a very powerful set of libraries, that allows good coders to design 3D graphics applications, which take full advantage of hardware-accelerated – i.e., GPU-based – rendering, of virtual 3D scenes designed by such users, into simulated 2D camera views, within the same scene. This is one of the most common modes in which 3D Graphics is operated.

One of the things that OGRE is not, is a full-fledged game engine unto itself. This is due to:

  • Lack of sound implementation (Additionally linking applications to the SDL Library may solve that),
  • Lack of scripting support, without some sort of add-on. I think I compiled it with Python support, which would supply scripting, if my coding was good enough.

Modern builds of OGRE break with the past, in that they no longer use ‘OIS’ as their input system. Instead, at least their Sample Browser uses the ‘SDL library’ to do the same.

One of the feats which I have now accomplished on the computer named ‘Phosphene’, which is a Debian / Stretch, Debian 9 system, was to compile version 1.11.5 of this engine because I’m curious about Game Design, which I have been for a long time. And one of the reasons I feel that this software is stable on Phosphene, is due to the information which I already provided in This past posting. The past posting announced observations which I made, when this same hardware was called the computer ‘Plato’, but already running Debian Stretch.

What my observation essentially suggests is, that running 3D, OpenGL applications can in fact break the compositor because they suspend it, but that there is a work-around.

(Updated 2/20/2019, 19h00 … )

Continue reading OGRE 1.11.5 Working on ‘Phosphene’