Welcome to the GlPortal issue tracker. New to the project? Try our simple tasks.

Advanced

Miscellaneous

Search in commentsSearch detailsSearch for all wordsTasks I watchTasks not blocking other tasksTasks blocking other tasksBlocker or nonblocker, selecting both filter options doesn't make sense.Has attachmentHide SubTasks

mesamatrix.net reports 100% support with free drivers. Proprietary drivers on Linux as well as other platforms should have it also -- it was "Approved by the ARB on February 17, 2009" and the implementation within drivers is technically simpler than Vertex Buffer Objects so it's likely implemented by now.

OpenAL is as cross-platform as SDL_mixer coupled with SDL_audio, if not more efficient as it is an OpenGL-like standard allowing for different system implementations, and OpenAL Soft which is almost the only implementation used supports many sound systems, is made from the ground up for 3D games, and even provides advanced features such as EFX (reverb, absorption) or HRTF.

If needs be the audio system can be made backend-agnostic using virtual classes, so we keep SDL_mixer if necessary.

It is multiple choice text adventure. You are presented with challenging situations (queue at the supermarket, boss yelling at you) and can decide if you want to keep calm and watch your breath or get angry and follow your impulses.

Task Description
Visible flow of current in circuits represented by painting the live circuit in another colour.
If performance is a problem, step the simulation very slowly. Add dotted semiconductors.

Draw a grid on the screen and the player has to close a circuit by painting in pixels. The circuit can trigger one or more triggers. This first version will likely have no challence except maybe have areas where the player can't draw.

At first all tasks will be to connect a cpu to the surrounding circuit like power supply.

As of early versions, the pixel fonts are good enough for the rendering we need.

However it has several issues:

A new font texture must be generated for each font we'll add

This font texture must be generated with a tool: extra code separated from glPortal's source. Plus currently it's distributed in conjunction with an EXE blob for Windows which is more than 200 Kb in size

This scales badly when upscaled and even when downscaled (with GL_LINEAR)
We use Signed Distance Field text rendering.

Is limited to a certain number of characters

It can't have an arbitrary font resolution; would not be a problem if we used explictly bitmap fonts, which is however not the case

The following is proposed instead:

If we use a library able to render strings, use this ability

Else, generate font atlases on the fly, possibly reusing SDFont's code, and keeping the Signed Distance Field technique to avoid requiring many atlases (1 per font size).

Of course, the results will be cached to improve performance, and likely garbage-collected or refcounted in the first case to avoid resource exhaustion.

Blender is a wonderful 3D editing software, however it isn't the best fit editor for glPortal maps. Maintaining the editor plug-in further will be a real headache if frequent changes are being done to the map format or if we add new elements.

Having an in-game editor would allow live preview and testing, no map compilation/conversion necessity, as well as easy new element integration as we use an Entity Component System, the only base requirement being to implement some kind of reflection framework (like .NET/Java) on Components.

On this image, the upper left one is the "modern" look, and the upper right one is the is the "old Aperture" look. Other fields colors are not part of the original game and has different purposes.

Inspired by this design, our fields can look similar but better by actually making them 2D water simulations, more popularly known as the "ripple effect", as popularized by this article. Here are a few HTML5 example implementations: 1, 2, 3, 4.

As described in the design ideas document, those fields would have their emitters stuck to the wall, either recessing or part of it. These could, on the 2D water sim, constantly create waves by setting the said simulation "pixels" to a sine function of time. Additionally, interaction from the player or any other physical object would actually make waves as the said object passes through the field. This effect should be able to be disabled and tweaked (resolution setting) in the settings, as it implies some rather heavyweight CPU-side computation and frequent CPU -> GPU texture uploads, which is limited by bus bandwidth. Use interpolation to our advantage.

However, due to the current (portal closing/portal bullet vanishing, object dissolving, player killing) and future different stacking functionality a single field can have, we must ensure the visual signals indicating those functionalities are stackable too. First off, R+G+B colors addition could do the trick. For further functions, things such as particles is an idea.

valgrind --tool=callgrind ./(Your binary)
It will generate a file called callgrind.out.x. You can then use kcachegrind tool to read this file. It will give you a graphical analysis of things with results like which lines cost how much.

08:10 < nfries88> also, he should not be comparing strings when he could be comparing identifiers or simply storing systems in an
ordered list: bool PlayerSystem::runsBefore(const System &sys) { const char *name = sys.getName(); return
::strcmp(name, "PhysicsSystem") == 0; }
08:12 < nfries88> even an optimized strcmp will take at least stringlength/sizeof(int) times as long as an integer comparison

06:58 < nfries88> ok I have to go to bed soon, but I have on last suggestion regarding radix engine, it will make it more flexible (so,
for example, the ECS aspect could be used for servers). Maybe you can pass this on to Dorian?
07:00 <@uwjesq> nfries88: Yes I can.
07:02 < nfries88> reduce the control that the World class has over Systems, or possibly eliminate it entirely and just have the
programmer using Radix invoke each system on command, and synchronize each system on command
07:03 < nfries88> presumably the Radix user will be implementing most or all systems himself anyway, so he can control how systems run
when implementing the systems
07:04 < nfries88> this would allow, in the server case, for most systems to be implemented to run asynchronously on a worker thread
that's just an asynchronous task pool
07:07 < nfries88> it also might be more proper to remove the dependency on bullet from the engine, and instead put the system
implementation in the GlPortal branch. This will make the engine useful to people who have physics requirements that
bullet does not meet.

07:14 < nfries88> For offline games or clients, this is probably fine, but it is making Radix::World into a black box systems
controller (black boxes aren't great), and it assumes all systems should be run synchronously in worker threads (this
does not work for servers)

07:18 < nfries88> it will make Radix slightly harder to use when system control is up to the user, but this gives more control to the
user to maximize performance with their specific requirements.
07:19 < nfries88> I am always happy to offer advice
07:24 < nfries88> Radix could also implement a worker thread pool class for this general case.
07:24 < nfries88> (it's basically what is already done in Radix::World anyway)
07:32 < nfries88> you might also want to open a task for adding an asynchronous file I/O implementation. I'm honestly amazed at how few
game engines include such a useful (and now almost universally available) feature

07:43 < nfries88> on Linux it is pretty easy with POSIX aio. I think there are several ways to do it on OS X, but POSIX aio is also
available there
07:43 <@uwjesq> nfries88: On windows not so much...
07:44 < nfries88> On Windows there is either ReadFileEx/WriteFileEx or I/O Completion Ports. I/O Completion ports is better.
07:44 <@uwjesq> nfries88: To windows users we show a screen "Loading very slowly... because windows."
07:44 < nfries88> lol
07:44 < nfries88> actually if Windows were more secure, and didn't have all that UI bloat by default even on their server versions, I
would only use Windows for game servers
07:45 <@uwjesq> nfries88: I know this one guy that is using windows servers. I only have ??? in my eyes when he talks about them.
07:46 < nfries88> I/O Completion Ports is much easier than the alternatives for network IO (and POSIX aio does not work for network I/O
- each family of Unix-likes have their own mechanism)

Currently, file RWops are blocking and synchronous (just like what's provided by the C FILE* and C++ fstream). This is all fine in good for non-interactive programs and initialization-time loading. But most applications of SDL are interactive, and many are games and media players, which need to read from the harddisk while remaining interactive.

Because file RWops are blocking (take control away from the main thread), reading too much data from the hard disk on the main thread makes programs non-interactive. This leads to messy solutions like creating another thread just to load data ( "Main thread renders loading animation while background thread uploads whole level along with textures. In fact I did notice that this takes slightly longer than doing everything in main but user experience is much better with main thread still operational, showing anims and gameplay tips. ": http://forums.libsdl.org/viewtopic.php?t=9897 ).

So, I request the addition of asynchronous I/O features to SDL.

POSIX non-blocking I/O is simple: pass the flag O_NONBLOCK to open(), and all calls to read/write will return without waiting for the disk (the return value will be the number of bytes written). Asynchronous file I/O was added to POSIX in 2001. Most versions of the interface do not work on sockets. See: http://pubs.opengroup.org/onlinepubs/009604599/basedefs/aio.h.html Non-blocking I/O can be multiplexed using select() in order to reduce the number of read()/write() syscalls: http://pubs.opengroup.org/onlinepubs/7908799/xsh/select.html With non-blocking I/O, SDL will have to maintain the total number of bytes written in order to determine when an I/O operation has completed.

Windows does not support synchronous (in order) non-blocking I/O. Instead it only supports asynchronous (out-of-order, or in Windows terms, overlapped) I/O. This is implemented by passing FILE_FLAG_OVERLAPPED to CreateFile and maintaining an OVERLAPPED structure for each I/O operation. See: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365683%28v=vs.85%29.aspx There are several ways to get indications of I/O completions using asynchronous I/O. One is to associate a kernel event with the OVERLAPPED structure passed to ReadFile/WriteFile. Another is to call GetOverlappedResult. But because an application that has real use of asynchronous I/O is probably performing operations on multiple files, it would be better to reduce the number of syscalls. This means using Read/WriteFileEx and entering an alertable wait state in the main loop (a new API function, SDL_PumpIO, for other threads; and probably inside SDL_PumpEvents) to execute I/O completion handlers. See: http://msdn.microsoft.com/en-us/library/windows/desktop/aa363772%28v=vs.85%29.aspx

It is entirely possible to implement this using the existing SDL_RWops interface. But an asynchronous SDL_RWop would break old code using SDL_RWops by its nature.

Instead, I recommend an additional API just for asynchronous file ops. While this could certainly be done as a third party library, I feel that it would be a better fit for the main library, using the SDL event queue to report completed/failed async ops with a new event.

After checking out and updating all submodules in the RadixEngine, i tried to compile the source :

CMake Error at CMakeLists.txt:17 (find_package):
By not providing "FindCXX14.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "CXX14", but
CMake did not find one.

Could not find a package configuration file provided by "CXX14" with any of
the following names:

CXX14Config.cmake
cxx14-config.cmake

Add the installation prefix of "CXX14" to CMAKE_PREFIX_PATH or set
"CXX14_DIR" to a directory containing one of the above files. If "CXX14"
provides a separate development package or SDK, be sure it has been
installed.