Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 28 May 2011
Offline Last Active Today, 07:49 PM

#5227319 GUI rendering application performance

Posted by Waterlimon on Yesterday, 09:21 AM

I did a bit of research but didnt find much...


Maybe you just have to implement a multitasking system of some sort for your rendering system, such that you can render the scene and UI at different rates.


For example:

-Scene and UI are both rendered to off screen buffers (with ping pong buffering or whatever you need to keep it smooth)

-At 60 FPS you merge the contents to the actual backbuffer and display


So if the scene draw is going at 2 FPS, it just means you will be copying the same rendered scene to the scene for about 30 frames, while the UI will remain interactive (assuming it can do 60 FPS)


You can optimize by drawing UI directly to backbuffer on top of the copied scene render (so UI render is tied to the 'main' 60 FPS rendering)



Now, how to actually separate the scene rendering from the stable 60 FPS render, Im not sure.

-Maybe multithreaded/multicontext (I dont even know if those are the same thing) rendering allows decoupling them?

-Maybe you can sprinkle 'check-if-60-FPS-UI-render-should-be-done' calls in the middle of the scene render:

1. Drawcalls

2. Check if UI + latest scene render should be drawn to maintain high FPS

3. Drawcalls

4. Check if UI + latest scene render should be drawn to maintain high FPS

5. Drawcalls

6. Update latest scene render buffer and draw it + UI


(If you didnt do this, it would just be sequential and be as slow as scene render FPS)



Im pretty sure the end result is going to be jittery graphics and unexplained 50% performance loss...


Maybe theres a way to make the OS do the prioritization, but I suspect it only works for OS internals (whatever draws the OS graphic thingys), so maybe it would only work if you do rendering on CPU and use some OS call to blit that to the window... Or some transparent child window on top of the game scene area... ew...

#5227279 DirectX device context map

Posted by Waterlimon on Yesterday, 04:46 AM

Do you actually resize the GPU buffers to fit the new data when updating them (or allocate enough extra space initially)? To me it seems you just map the original-sized buffers and memcopy more data in them than they can hold...

#5227049 Font Rendering without bitmap textures for localization

Posted by Waterlimon on 03 May 2015 - 06:22 PM

What I do is:


I have classes:


Font (basically a font file, to load individual glyphs based on unicode code point)

Glyph (unicode code point)

GlyphData (get this from font given a glyph, tells you glyph size, offset, and you can ask pointer to glyph bitmap all provided by freetype)

TextureAtlas<KeyT> (just normal texture atlas, I typedef this as GlyphAtlas = TextureAtlas<Glyph>)

TextRenderer (Basically contains a string I want to render + a mesh for the actual rendering of it)


.createGeometry(font, glyphAtlas) //if a glyph isnt in the atlas, load the bitmap using font and add it there. Create a vertex buffer with UVs to the atlas.

.render(renderer, matrix) //Or however you want to do the rendering, I only ever used this to render a small FPS counter tongue.png


You can improve by supporting multiple fonts for a piece of string, and adding another class for formatting the string (newlines, text wrapping...) before creating the geometry




So the bitmaps for glyphs are loaded from freetype as they are used and put into a big atlas. So you can throw whatever text at it and it loads the needed glyphs. You might want to do a 'preload' pass sometimes, to load characters you know youll need instead of loading them in the middle of gameplay (might slow down?). Eg load at game start, or level load, or offline (eg scan through all game texts, and render all characters into some default atlas so you dont have to use freetype to render those at runtime)


Ideally you could also remove loaded characters from the texture atlas if theyre unused (eg if you allow chat in whatever language, and someone decides to chat all unicode characters on by one, you dont want to keep them around forever just because they were needed for a single time...)


So the 'bitmap'/texture atlas (or whatever you use) is filled in at runtime as specific glyphs are needed to be rendered (whatever language it is).

#5227042 Align Vertices to Average Plane ?

Posted by Waterlimon on 03 May 2015 - 06:05 PM

This stackoverflow question seems to contain a simple description of how to do it in the question itself (the question asks how to do something else, but also explains how your issue is solved)


Here is the relevant contents:



I am fitting a plane to a 3D point set with the least square method


Compute the sum:

for(Point3D p3d : pointCloud) {
pos = p3d.getPosition();
fSumX += pos[0];
fSumY += pos[1];
fSumZ += pos[2];
fSumXX += pos[0]*pos[0];
fSumXY += pos[0]*pos[1];
fSumXZ += pos[0]*pos[2];
fSumYY += pos[1]*pos[1];
fSumYZ += pos[1]*pos[2];

than make the matrices:

double[][] A = {
{fSumXX, fSumXY, fSumX},
{fSumXY, fSumYY, fSumY},
{fSumX, fSumY, pointCloud.size()}

double[][] B = {

than solve Ax = B and the 3 components of the solution are the coefficients of the fitted plain...


In the comments it warns about this possibly resulting in numerical error because of summing squares if theres many points, so might want to solve that by converting all the points to be relative to the mean position and maybe doing the summing in blocks (eg do the sums for blocks of N vertices, then sum all those together) or even hierarchially if theres a silly amount of vertices (to avoid having to add two very different magnitude numbers together)... or maybe its enough if you use double.

#5227028 open source space simulation to clone major titles like elite dangerous, star...

Posted by Waterlimon on 03 May 2015 - 04:57 PM



I cant comment it because all of it is either unrealistic, doesnt fit together with the other stuff, or is too specific to even think about at this point. You should use it as the primary source of entropy for the random generator.


However I did find this chunk that might explain what the list is:

initial plan is to make rough note, consolidate nots, make more rough notes, consolidate once more, pich storyboard, develop rough prototype of game features and brainstorm mapping, introduce a small number (12-18 people) for dev team positions and meetings about the new project and areas ox expertise as well as ability crossover, write a website about the project, then attain crowdfunding to pay for development and 66% life salary goals, release pre-alpha to backers, release alpha to backers, release beta early for backers and then to general public, have final version and three expected patches for total open source release. Open release available early to backers of the project, with delay of 3 months before releaseing open source. Plan to keep project alive for 6-8 years with open source forum created for gameplay after official release.

Whole product is open source and we make our money from donations and crowdfunding (everybody should expect to make 33% to 66% of their life income from this project

Which makes it a bit more reasonable (assuming its the first 'rough notes')

#5226190 how to construct directional light emitting source

Posted by Waterlimon on 28 April 2015 - 08:36 PM

Do you mean an area light (a finite surface emitting light), or an actual directional light (global light coming from a specified direction with no physical source unless its approximating one, like the sun)?


If you mean area light, im under the impression that those are difficult to get right (though if you search with that term youll find resources) - for point sources (point lights, spot lights) its easy to calculate intensity of light based on distance, however when youre working with a surface, calculating that is nontrivial (you basically have to integrate the intensity over all the points on the surface for an exact solution)


Then theres shadows and all the other things, everything gets complicated.


So usually some approximations are used, eg calculate intensity based on distance to closest point on the area light, or just pile a couple of normal point/spot lights on the area light surface and call it finished (this is probably what most people do).

#5226111 Carousel slider - user experience

Posted by Waterlimon on 28 April 2015 - 11:50 AM

The arrows are redundant.


Clicking left means 'Select the left item'.

You already have a button for the left item, with apparently no function.


So why not remove the arrows, and make it so that clicking an item moves that item to the center (same functionality as arrows)

Optionally put a transparent arrow overlay on the leftmost and rightmost items to indicate that pressing them essentially scrolls left/right.


This way you will save space, while also making it possible to more directly select a visible item (Instead of thinking about how do I get this item to the center so its selected, I can just press the item and itll be selected automatically)

#5225857 Character control from a Physics Engine perspective

Posted by Waterlimon on 27 April 2015 - 08:53 AM

For the dynamic approach, you could just change the magnitude of force applied depending on current velocity (in the direction youre trying to move? dot product of velocity and direction of force)


So if you try to move from stationary state, or move in a direction that is opposite/perpendicular to current velocity, you could apply a higher force than if you already have velocity in the correct direction.

#5225469 Direction Booleans into single Integer

Posted by Waterlimon on 25 April 2015 - 10:41 AM

int lookup[3][3] = {
int direction = lookup[1+down-up][1+right-left];

I thought this is a nice way to represent it if you go with a lookup... Array has only the values you need, and theyre arranged visually so its easy to change them if you want. You can easily extend it into 3D too if you need another axis of freedom.

#5225128 Collision Detection and Camera movement. C#/Monogame

Posted by Waterlimon on 23 April 2015 - 03:35 PM

For #1:


Youd probably have something like:


1. Tile instance data. This is contained by every tile in your map grid (currently you have an integer 0,1,2,3...). As said, made this an object so you can easily add more per-tile-instance data.

2. Tile type data. This is new. For each type of tile, make an object (add all these into a single array lets say in a TileTypes object). So you can store the properties (physical, visual, behavioral) of a tile type here, without wasting memory by copying the data for every tile instance. Things like "collides", "friction", "texture", "name", "touchedBehavior".


Then, in a tile instance, you would have an index to a single tile type. If your tile instances contained just a single integer (like now), this could be an index to a tileTypes array. So, if 0 is sand, you set tileTypes[0] = new TileType("sand", "sand.png", collide=true) or something like that for each tile type.


The general pattern is that you have a bunch of information shared by multiple objects, so you put that shared information in one place and make all the dependent objects refer to it using an index/handle or a reference of some kind.


For 2#:


Yup, here you just maintain a camera object with a position in world-space (x,y), and when drawing stuff you need to draw it relative to the camera (screenPos = objectWorldPos - cameraWorldPos). If you dont have zooming or rotations, its basically just offsetting by the cameras position in the right places to convert coordinates between world<=>screen. I suggest writing worldToScreen and screenToWorld type functions to easily do these conversions and not get confused. Then eg when drawing a tile, knowing its position in world, just do worldToScreen(tilePos) to know where on screen to draw it.


Moving the camera when mouse is on screen edge should be pretty easy, just detect what edge mouse is on and then apply camera movement based on that (to do it properly youd want to move by constant amount per second, instead of eg 10 pixels per frame, since frame rate is not a constant usually and your camera movement speed would change from time to time if you dont take frame duration into account)

#5224739 Ideas for a seminar in computer graphics

Posted by Waterlimon on 21 April 2015 - 01:29 PM

Maybe something about management of levels of detail... This is relevant to almost any area of computer graphics (whatever you draw, you can draw at many distances from the viewer) so you can set the scope pretty freely.


Things like having different LoD levels for meshes, tessellation, impostors, procedural generation, texture resolution/mipmapping...

Practically: Terrain LoD, rendering planets all the way from space to surface, keeping shadows just the right quality...

#5224344 is it possible to program one app with different languages?

Posted by Waterlimon on 19 April 2015 - 01:42 PM

Well first, you of course need the 'core' language with the crossplatform code to run on all the platforms (c++ in your example).


Then, you might have more cross platform code written in another language. Communication with these depends on the language and the "FFI" mechanism it implements as explained (usually calling C-like simple functions is supported, possibly with special requirements/constraints to make sure it works properly).


Then, there might be platform dependent libraries written in another language OR the same core language. With C++, you would write the code for each such platform dependent library, and then at compile time choose which piece of code you want to compile using preprocessor directives (if its windows, use this block of code, if its mac, use this next one and so on). This would be done such that whatever platform dependent library you choose, the interface is the same, so the cross platform code can use it the same way (eg you might have a function that does something, and the implementation of it changes depending on platform. So the interface doesnt change)


Though just because the interface for such a cross platform functionality implemented differently for each platform doesnt change, its behavior might. Eg if it was some kind of rendering class, on one platform it would report that it supports some maximum size of texture, and another platform the maximum size might be different. But thats a part of the interface so its ok.

#5224338 Updating an entity component system asynchronously

Posted by Waterlimon on 19 April 2015 - 01:10 PM

In an entity component system, there really are no 'objects' or 'entities', so it would be wrong to say that one entity must be updated before another. Components might have update order constraints WRT to other components or systems.


I think the point is more that with ECS systems, objects tend to naturally be organized in a cache friendly way, and if they dont, its very easy to make it happen.


If there are no dependencies between components of the same type, you can update components of that type in any order (perhaps using worker threads to divide the workload) so its not an issue there, and I would say most components are like that. Instead, dependencies tend to be between types of components, where its easy to just update the different systems in the correct order.


In the cases where components might depend on others of the same type, you still can design the system such that its cache friendly:

  1. You could see if its possible to make the components accept data from previous update instead of current one (so update order doesnt matter within a single frame)
  2. You could store the components sorted in an array such that 'parent' components come before 'child' components (flattened tree), cache friendly and update order is correct, downside is that there will probably be some indirection cost and sorting cost since components cant stay in the same position forever.
  3. If your dependency tree has finite depth, you could split the components of that system into multiple levels where each level is a 'normal' cache friendly component storage thingy (similar to how you might have pre-update, update, post-update etc.)
  4. Use whatever data structure you have to use. Its not like you need to do this for every type of component and its not like you would have better options without ECS.

#5224333 A brief discussion on design: handling visibility

Posted by Waterlimon on 19 April 2015 - 12:00 PM

Aww I wrote some stuff and accidentally hit backspace...


Anyways, I had the following idea:


First, the map has to be randomly generated.


You can only see the portion of the map directly/indirectly seen by currently active unit (units should share their view if theyre close enough).


Now, the player can draw freeform maps (either using some kind of pencil, or annotated points, or hexes, whatever). The map is in no way linked to the real world (it wont show where your units are, it shows nothing, everything is added on it manually).


So if the player sends out an exploration team, they get pushed around a bit by wind, end up in a storm, and after 10 years find land, the player has barely any idea where they are.

The player will explore around a bit with this exploration team, drawing a local map (centered around the "landing point" for example).

Now, the player also has a local map for the main base.

Then, the player can create a 3rd map, name it "global map", and drag and drop the two local maps onto this global map as single entities, positioning and rotating them in an attempt to make their relative positions as accurate as possible (perhaps the player knows the approximate direction the exploration team went, and the approximate speed, and hopes they didnt do a 180 turn on the way)

When further information is received, the player can adjust the global map by repositioning the local maps.

There can be as many maps as the player wants, and any map can be included in any other maps as many times as the player wants. So the player could have a map for each continent (filled with local maps), and a global map with the continents glued together.


Now, this mapping process takes time and effort, so it should obviously be central to the gameplay to make it worth implementing.


The maps are needed for efficient long distance navigation, so what can we do to make that really important?:

  • Unique resources found in far away places (find a way around the globe to get there faster? Maps should wrap around and be of random size so you never really know if you got around the planet or if you covered 25% of the map or if you circled it 4 times)
  • Knowing where an important location is on one local map, but needing to know where it is relative to another to be actually able to get there. Eg Exploration Team finds a map to a treasure. The map is relative to their current location and the player can use landmarks to figure out where the treasure is on that local map. But the Exploration Team lacks the resources to go after it, because of course its on another continent entirely. So, you need to know where the treasure is relative to Main Base in order to send a stronger team for it. In order to do this, you need to have a reasonably accurate global map where both the local map of Exploration Team and the local map of Main Base have been placed. If you have such a map, you will immediately know where to go from Main Base to get to the treasure. If you dont have a map like that, youre not getting there any time soon.
  • Knowing where the enemy is relative you in all directions once you find them. Maybe you only explored to the west (Wherever that is...) and find the enemy far away, but if you explored east you might have found them much closer to you. If you have a good global map, you would realize this immediately, but if you dont know the size of the planet, youll have no idea.
  • Maybe you need to create maps for traders or allies to properly interact with them. If your maps suck, the traders will never get to you and neither will your allies when youre in trouble. (it could be interesting if you could share your maps with your allies in multiplayer, so they can use them as parts of their global maps, or maybe teams have a combined pool of maps editable by the entire team)


Overall this could be fun, but the games will have to be very long (not a problem if single player. But for multiplayer It might make sense to have big teams where people can come and go, but the maps remain. Thats how maps evolved in real life anyways... Difficult to implement well though)

#5224257 how much xamarin and other cross platform api,s are good?

Posted by Waterlimon on 18 April 2015 - 07:20 PM



It says on iOS its compiled to a native ARM executable ahead of time, on android it doesnt explicitly say that (see this stackoverflow answer for reasons why). And it says ("your Xamarin app is compiled to a native binary, not interpreted") without specifying which platform, so both probably.