Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

26. June 2017


The Esenthel Game Engine has been under development for more than a decade and yet I had never actually tried it before now.  They recently released a Fantasy Tech Demo illustrating recent functionality added to the engine.  After trying out the demo, I decided to give Esenthel a shot.  The following video is a quick hands-on with the Esenthel Game Engine. Esenthel is a C++ powered/scripted game engine with a full editing environment as well as Visual Studio integration.


The Essenthel Engine has a free trial available for download and is available for Windows, Mac and possibly Linux.  The full version is a commercial subscription for 11.40$ a month or 114$ annually.  A source license costs double that amount.

Programming ,

2. August 2016

 

Allegro is a C/C++ game library with a found place in my memory.  It was one of the very first, freely available open source 2D C/C++ frameworks and it continues to be developed to this very day.  In fact, Allegro 5.2.1 was just released.

 

From the change logs.

Core:

  • Optimize bitmap holding a bit (Bruce Pascoe).

  • Add al_get/set_depth/samples (OpenGL only for now).

  • Optimize destruction performance when you have thousands of objects (e.g. sub-bitmaps).

  • Use low floating point precision for the OpenGL fragment shaders, which helps performance a lot on mobile platforms.

  • Don't stop and join the timer thread when stopping the last timer (prevents unnecessary delay in this situation on some platforms).

  • Add al_backup_dirty_bitmap and al_backup_dirty_bitmaps to more finely control when bitmap context backup is performed.

Android port:

  • Fix Android app issues when woken up during sleep.

  • Specify the Android toolchain file on the command line now. ANDROID_NDK_TOOLCHAIN_ROOT now has to be specified in an environment variable.

OSX port:

  • Improve joystick enumeration (Todd Cope).

  • Make al_set_new_window_title work correctly.

  • Don't send duplicate mouse move events.

  • Fix mouse warping behavior.

  • Exit fullscreen mode if ALLEGRO_FULLSCREEN_WINDOW is set when destroying a display (otherwise if you destroy and recreate display without terminating the program, a white window kicks around).

iOS port:

  • Make it compile again.

  • Don't backup textures as it is unnecessary.

  • Update minimum iOS to version to 6.1.

  • Disable the native png loader in favor of libpng, as it is broken on Apple's end.

  • Create library when creating the archive.

Windows port:

  • Fix the D3D target bitmap bug.

  • Clear display to black right away to avoid an ugly white flash.

Raspberry Pi port:

  • Fix system cursor support.

Linux port:

  • Make al_set_new_window_title work correctly.

Build system:

  • Use PROJECT_SOURCE_DIR and PROJECT_BINARY_DIR instead of CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR. This lets you use Allegro as a sub-project in your CMake project.

  • Fix GDIPlus finding in cmake-gui (Bruce Pascoe).

  • Add .gitignore and ignore build/ dir (Mark Oates).

  • Fix building examples with non-Allegro dependencies with the monolith build.

Documentation:

  • Various documentation updates (Daniel Johnson and others).

Other:

  • Add more #include statements in Allegro headers, so it's easier to use them in isolation (Jordan Woehr).

  • Allow marking tests as being hardware only.

  • Prefix some private Allegro macros and types to not pollute the namespace.

  • Make set_shader_uniform api const-correct (Bruce Pascoe).

Audio addon:

  • Adjust loop end position when calling al_set_sample_instance_length.

Acodec addon:

  • Allow file-backed audio streams to be restarted after they finish.

  • Add Opus codec support.

Image addon:

  • Fail gracefully if not built with PNG/JPG loaders.

Native dialog addon:

Font addon:

  • Make al_get_text_dimensions and al_get_glyph_dimensions return exact bounding boxes (koro).

  • Add ALLEGRO_GLYPH structure and al_get_glyph, allowing for some additional optimization when drawing fonts.

Examples:

  • Add more controls to ex_audio_props.

  • Add an example of using Enet with Allegro.

GameDev News

24. July 2016

 

Traditionally I don’t recommend beginners start with C++.  There are a number of reasons behind this opinion, most of which are explained in this video.  Most of the reasons however have very little to do with the language itself (which does of course have some downsides) and more to do with the build system, linker and limited included libraries.  I recently discovered a library aimed at beginners that alleviates a great deal of the downsides of learning using C++, raylib.  It’s free, open source (available on Github) and provides most of the functionality you require to make a game.  Most importantly, it’s aimed at beginners meaning the library is easy to use and comes with a turn key installer that enables you to hit the ground running.

If you are interested in learning more about raylib, be sure to watch this video (also embedded below).

 

The key features of raylib are:

- Written in plain C code (C99)
- Uses C# PascalCase/camelCase notation
- Hardware accelerated with OpenGL (1.1, 2.1, 3.3 or ES 2.0)
- Unique OpenGL abstraction layer (usable as standalone module): [rlgl]
- Powerful fonts module with SpriteFonts support (XNA fonts, AngelCode fonts, TTF)
- Outstanding texture formats support, including compressed formats (DXT, ETC, ASTC)
- Basic 3d support for Geometrics, Models, Heightmaps and Billboards
- Materials (diffuse, normal, specular) and Lighting (point, directional, spot)
- Shaders support, including Model shaders and Postprocessing shaders
- Powerful math module for Vector and Matrix operations [raymath]
- Audio loading and playing with streaming support (WAV, OGG, XM, MOD)
- VR stereo rendering support with configurable HMD device parameters
- Multiplatform support: Android, Raspberry Pi, HTML5, Oculus Rift CV1
- Custom color palette for fancy visuals on raywhite background
- Minimal external dependencies (GLFW3, OpenGL, OpenAL)

 

The part I found most impressive though is the installer.  It comes with a pre-configured version of the MingW compiler and Notepad++ set up for development right away.  Basically you run the installer, open notepad++, start writing code and hit F6 to run it.  No dealing with setting up a compiler, learning about linkers and all the various things that make the C++ learning curve so painful.  Well, most of the things...

 

I should point out quickly, while I’ve been calling it a C++ library, it’s actually a C library.  This is a minor distinction as it is perfectly usable in C++ and feels like C++.  It comes with a copious amount of examples, with very easy to understand code.  Here for example is an, um, example that illustrates loading and drawing images:

/********************************************************************************
***********
*
*   raylib [textures] example - Image loading and drawing on it
*
*   NOTE: Images are loaded in CPU memory (RAM); textures are loaded in GPU 
memory (VRAM)
*
*   This example has been created using raylib 1.4 (www.raylib.com)
*   raylib is licensed under an unmodified zlib/libpng license (View raylib.h 
for details)
*
*   Copyright (c) 2016 Ramon Santamaria (@raysan5)
*
*********************************************************************************
***********/

#include "raylib.h"

int main()
{
    // Initialization
    //---------------------------------------------------------------------------
    -----------
    int screenWidth = 800;
    int screenHeight = 450;

    InitWindow(screenWidth, screenHeight, "raylib [textures] example - image 
    drawing");

    // NOTE: Textures MUST be loaded after Window initialization (OpenGL context 
    is required)

    Image cat = LoadImage("resources/cat.png");             // Load image in CPU 
    memory (RAM)
    ImageCrop(&cat, (Rectangle){ 100, 10, 280, 380 });      // Crop an image 
    piece
    ImageFlipHorizontal(&cat);                              // Flip cropped 
    image horizontally
    ImageResize(&cat, 150, 200);                            // Resize flipped-
    cropped image
    
    Image parrots = LoadImage("resources/parrots.png");     // Load image in CPU 
    memory (RAM)
    
    // Draw one image over the other with a scaling of 1.5f
    ImageDraw(&parrots, cat, (Rectangle){ 0, 0, cat.width, cat.height }, (
    Rectangle){ 30, 40, cat.width*1.5f, cat.height*1.5f });
    ImageCrop(&parrots, (Rectangle){ 0, 50, parrots.width, parrots.height - 100 }
    ); // Crop resulting image
    
    UnloadImage(cat);       // Unload image from RAM

    Texture2D texture = LoadTextureFromImage(parrots);      // Image converted 
    to texture, uploaded to GPU memory (VRAM)
    UnloadImage(parrots);   // Once image has been converted to texture and 
    uploaded to VRAM, it can be unloaded from RAM
    
    SetTargetFPS(60);
    //---------------------------------------------------------------------------
    ------------

    // Main game loop
    while (!WindowShouldClose())    // Detect window close button or ESC key
    {
        // Update
        //-----------------------------------------------------------------------
        -----------
        // TODO: Update your variables here
        //-----------------------------------------------------------------------
        -----------

        // Draw
        //-----------------------------------------------------------------------
        -----------
        BeginDrawing();

            ClearBackground(RAYWHITE);

            DrawTexture(texture, screenWidth/2 - texture.width/2, screenHeight/2 
            - texture.height/2 - 40, WHITE);
            DrawRectangleLines(screenWidth/2 - texture.width/2, screenHeight/2 - 
            texture.height/2 - 40, texture.width, texture.height, DARKGRAY);

            DrawText("We are drawing only one texture from various images 
            composed!", 240, 350, 10, DARKGRAY);
            DrawText("Source images have been cropped, scaled, flipped and 
            copied one over the other.", 190, 370, 10, DARKGRAY);

        EndDrawing();
        //-----------------------------------------------------------------------
        -----------
    }

    // De-Initialization
    //---------------------------------------------------------------------------
    -----------
    UnloadTexture(texture);       // Texture unloading

    CloseWindow();                // Close window and OpenGL context
    //---------------------------------------------------------------------------
    -----------

    return 0;
}

 

All examples are a single .c file and there are plenty of them.  All you need to do is open them in Notepad++ and hit F6 to run.

 

At the end of the day, I still don’t personally think C++ is the ideal language to learn game programming, or programming in general.  However if you are going to start using C++, raylib is the single best starting point I have ever seen.  In fact, let me know if you would be interested in a beginner C++ tutorial series built around this library, let me know!

 

The Video

Programming

12. July 2016

 

Today Torque 3D released version 3.9 and in a somewhat odd release blog post they spoke mostly about the plans for the next release.  Torque is an MIT licensed open sourced 3D game engine written in C++.  This release constitutes 515 commits with the major releases being proper roll over to deferred renderer, an initial implementation of entity/component and DirectX 11 integration.

 

As mentioned earlier, the majority of the release blog post covers features intended for the 4.0 release:

So, here's a main features list that we're looking at bringing into Torque for 4.0:

  • Physically-Based Rendering. This is, unsurprisingly a pretty big one. Luckily, it's also most of the way done! The only main piece that needs finishing is reflection probes, and the core features are in. From there it would just be a matter of dialing in the supporting art pipeline and tweaking the math to make it look as good as possible.
  • MacOS support. This was originally slated for 3.9, if you look at the 3.8 release blog, but a lack of machines to test on, and the age-addled old platform code made it impractical to really tackle initially. The good news is, near the end of 3.9's development, with SDL and epoxy to take a LOT of the workload off, huge strides were made and it's actually almost completed. There's still some issues with rendering on some machines and catching errors and warnings that crop up, but it's looking very practical to have MacOS as an official platform for 4.0! You can see Timmy's screenshot in the 3.9 RC thread showing off T3D running on MacOS with his and JeffH's work now.
  • SDL as the main platform layer. Torque3D's supported SDL for quite a while now, and it's naturally the main platform layer for Linux(and MacOS). However, it's been a little bit of a red-headed stepchild to the Win32 platform code. For 4.0, that's changing and SDL will be adopted as the core platform layer with whatever glue needed sitting atop it. This will drastically simplify the platform code and make it easier to maintain. It also offers a good bit of future proofing should any other platforms come into the equation down the line. SDL's stuff is very nearly at parity with the Windows side, it's pretty much just a matter of jumping over the last bits and doing cleanup/bugfixes to make it rock-solid.
  • New Project Manager The old project manager was useful, but was hacked together with QT and php, so maintaining it was a little sketchy and fell by the wayside for the more standard CMake gui. However, there's lots of management things CMake can't do, which is why the Project Manager will be making a comeback, it'll just be a graphical frontend sitting upon the more standard cmake project generation. This new PM will let you manage your updates, and hopefully in the future hook into online repositories for easier grabbing and integration of updates as well as fetching content packages without hassle.
  • New Shadergen As great a job as the current workhorse does of generating shaders for all the many materials you need to make a game, updating and expanding it has proven to be a pretty annoying thing to deal with due to how it's structured. Excellent peice of tech, but a chore to maintain, just like ye olde German tanks in WW2. As such, we'll be looking into restructuring shadergen to not only make it easier to update and expand upon in the backend-sense, but also easier to build materials/shaders for the end user as well, up to, and probably including a node-based approach for engineering your fancy shaders for your fancy materials.
  • Graphics API refinements DirectX 9 has proven to be a monstrous workhorse of the graphical APIs, reliably serving well beyond what anyone though it would. However, while it has proven to be a rock-solid API, the time has come to retire the poor girl and send her off to the glue facto-eeeer, the farm. Yes. As such, DirectX 11 will be taking over as the main Dx rendering API, and will continue to see refinements to bring it up to speed now that Dx9 isn't hampering it or OpenGL. Timmy's been poking at this and has noted improved performance in Dx11 by quite a lot, and some gains in OpenGL as well.
  • Threads. Threads for days One major blocker to rendering performance that even dropping Dx9 won't help is that we curretly don't thread or do much to optimize out the render calls themselves. That'll change in 4.0. We've been brainstorming the optimal approach for a few months now and have a pretty solid plan of attack that will see the render calls threaded out, and also proper batching of rendered geometry where appropriate. So fewer, faster drawcalls for the same workload. We'll also be looking at threads for handling resource loading and spawning of objects to cut out all those hitches when the map starts or stuff is created.
  • Hardware Skinning Another thing that's been pretty much complete outside a few oddball behaviors we'll be getting in there is Hardware Skinning. When it's behaving, the current implementation already notes a huge improvement in performance for animated meshes, so getting it polished up and in should be a huge, immediate performance boon.
  • Physics API T3D's had a physics abstraction layer for a long time now, and it's been pretty useful in letting the end user decide if they wanted PhysX or Bullet. However, Torque's stock physics has still served a useful niche in being network-reliable, or lightweight for basic physics mechanics, and some people find it to be a pretty workable thing. As such, the Torque physics will be converted over into a Physics plugin, so all physics and collisions will go through the Physics API and standardize all the behavior for that across the engine, cleaning up quite a lot and making it easier to maintain.
  • Entities, Components, and Assets This is the big one from non-rendering side. 3.9 already has the initial implementation of the entity/component stuff, as well as the Assets/Modules systems, but they're not yet fully utilized. That'll change in 4.0. If you've been checking out my work blog with the recent updates, I've been covering work I've been doing on the improved asset pipeline, as well as continued work with the Entity/Component stuff. For 4.0, this will become the standard, and all existing gameplay classes(Vehicle, Player, Item, Shapebase) will be replaced with GameObjects built of entities and components to do the same work. The idea is to give users a similar base to what is in Torque now in terms of starting objects, but remove all the bulky, hardcoded functionality. It should be a standard point, not an anchor, after all. Tying to that, we also will have:
  • Assimp support This was actually mostly done back in the day, just some issues with animation stuffs and a few other minor problems. I'd poked at this with some R&D time a while back, so it shouldn't take much tweaking to get it polished up and hooked into the assets system, which will allow quite a few new 3d model formats, including FBX.
  • A new base template This is also basically complete. This will be a much more streamlined starting template intended to easily drop in modules, assets and the like into to build up your game project, as opposed to having to spend time stripping out the stuff you don't need. Numerous ancillary improvements also help load times, easier to read and comprehend code and the like. This will replace the empty and full templates, cutting down on the effort needed to maintain(no need to duplicate changes).
  • Vive support This comes from our own Mango's efforts. It's pretty much done, but didn't quite squeak in for 3.9. It will be going into 4.0 for sure.

GameDev News ,

27. June 2016

 

Marmalade is a popular C++/Lua (via Quick)  cross platform game engine that was used to make games such as Call Of Duty – Black Ops Zombies and Gods of Olympus.  Today they announced the release of version 8.4.  By far the biggest component of this release is that C++ 11 support is officially out of beta and available for use.  Additionally there were several fixes and a few deprecated platforms, including:

  • s3eCamera can now return high quality still images on Android, rather than the viewfinder preview
  • Windows 10 ARM builds can now be directly deployed to any attached device without any special configuration
  • Apple Pencil pressure reading is now supported on iPad Pro in addition to existing 3D Touch support
  • Slide Over and Split View multitasking now available to Marmalade apps on iOS 9 on supported devices
  • s3eWebView updated to use newer version of Chromium Embedded Framework on Windows Desktop

...and many, many more. For full details, please see the 8.4 release notes.

And finally, as announced earlier in May, this release also sees the removal of several technologies that have reached end-of-life:

  • LG Smart TV platform
  • BlackBerry platform (both BlackBerry 10 and BlackBerry PlayBook)
  • MIPS (an Android-only architecture)

You can continue to use these technologies through older releases of the Marmalade Platform but these are now officially no longer supported.

 

You can read more about the release here.

GameDev News

Month List

Popular Comments