Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content Count

  • Joined

  • Last visited

Everything posted by Ma-Shell

  1. Please don't use Window::MoveMouse! You will have users constantly asking themselves, whether that's absolute (i.e. move mouse to x, y) or relative (i.e. move mouse by dx, dy). Even if you can easily look it up I think, it is more helpful when scrolling through the autocompletion-options to just see on the first look what the function does without ambiguities.
  2. Pretty sure "appstores" is wrong, though^^
  3. I don't even know what the f*** is going on with all the appstores?^^
  4. This is looking great. I've always been bothered by the available options for a lightweight GUI. I also think that cross platform support for a GUI framework is quite a big deal and can only second the opinion that this is the most important bonus goal. From the material you have posted, there is one thing I am quite curious about: In your code example you are placing the button and panel using fixed coordinates and sizes. Moreover, the widget is only created once and does not run through a loop, where the user would constantly recalculate the coordinates. When looking at the video, howev
  5. You might want to look at the return code: in your batch-file add echo %errorlevel% directly after the game and before the pause
  6. Have you tried temporarily turning off windows firewall?
  7. Arrays use a single continuous memory block. If you want to enlarge your array you need to copy all data to the new location. However, when you want to randomly index the array, this can be done in constant time, so accessing x[5] is just as fast as accessing the first element or the last one. Vectors are basically a sort of managed arrays. They take care for reserving more space than you actually requested, so they can dynamically be increased and decreased in a limited manner without a performance hit. Lists are usually linked one element to the next. This means, for accessing the
  8. I suppose, that would be the case. There might be some other optimizations for brushes (e.g. if you want to have a sphere, you can simply transfer the center and the radius to the GPU instead of multiple vertices and again save some bandwidth and RAM real estate) but I believe that these differences would be only minor. I should say though, that I have never done any comparison nor do I have any specific knowledge of how this is implemented. Everything I'm saying about that topic is just derived from things I gathered in different forum posts here over the years and using my own logic
  9. The difference comes from the fact that the entire thing is collapsed to just a single model. This means that every piece of code, which iterates over all instances only walks over this object once instead of 1000 times. Also there is only one transformation matrix which is getting updated and pushed back and forth from CPU to GPU and which takes much less space (which can be used for caching again)
  10. What happened to where you claimed 200 fps for 10000 characters? Was that all shared skeletons?
  11. Ma-Shell

    Particle Physics

    This is certainly a pretty cool feature! Whenever physics is involved, however, the programmer needs to keep in mind that there might be slower systems out there and things might break when executed on slower systems. The programmer might e.g. be tempted to give an option to reduce the particle effects on lower end hardware but then the entire physics might break.
  12. I suppose, texcam will be rendered every frame, just like the normal camera. Would there be an option to render the camera only on demand? Like some sort of photograph? Or with a lower frequency for performance optimization?
  13. Are you using some fancy new technology like MVR or one of its predecessors for the single pass point-lights? If so, have you also evaluated, what happens on older GPUs?
  14. There is but that isn't trivial to implement: Basically you create a grid where each cell lists all the enemies within the region. This requires that when an enemy changes position, it also removes itself from the old cell's list and inserts itself into the new one. Then the player only has to search through the lists of the nearby cells. Of course the additional bookkeeping might have a different performance impact but especially, if the entities also sometimes react to one another or if you're checking the distance more often, this will certainly pay off.
  15. What does the code for differently coloured letters look like? Do you call CreateText once for every letter and then position them manually or is there a nicer way?
  16. Is it possible to combine more than 2 worlds (possibly by daisy chaining them)?
  17. I see two possible issues with filters: 1. I understand a filter as having some sort of "layer-id" on the objects and a camera only rendering objects with a given layer-id. Suppose, you have two objects A and B. If you want to first render A and B and then from a different camera only B (e.g. you have a vampire in front of a mirror. You would want the entire scenery to include the vampire but when rendering the mirror, you would want to render the scenery from that perspective without the vampire). This would not be easily possible with a layer-id. 2. Performance: You have to run throug
  18. Isn't that basically what a world is? Each camera renders only the objects that are in its world, so the world is basically a filter for the camera
  19. Ah, I see... So the rendering always uses the last world, which called World::Render() and uses all cameras from that world in the specified order? Would it be possible to implement the same ordering as with cameras for worlds then? Like the following realWorld->setOrder(1); HUDWorld->setOrder(2); where it would first render all cameras from realWorld and after that all cameras from HUDWorld. This would probably mean, it is more intuitive to have the render-call on the context instead of the world, since all worlds would be rendered. By the way, is there any
  20. You mean, because unlike the previous version the user does not directly call Render() anymore, since it is run on a different thread and thus the user can not correctly orchestrate the rendering? This should not be a problem, since in CreateCamera you can specify the world. auto realCamera = CreateCamera(realWorld); auto HUDCamera = CreateCamera(HUDWorld); realCamera->setOrder(1); HUDCamera->setOrder(2); realCamera->SetClearMode(CLEAR_DEPTH | CLEAR_COLOR); HUDCamera->SetClearMode(CLEAR_DEPTH);
  21. Would it be possible to use two different worlds for this? One "real" world and one for your HUD and then first rendering only the first world and after that rendering the HUD-world.
  22. The model probably does not have a surface. You should get the number of surfaces first and then iterate over the surfaces. Something like the following (I don't know much about lua, so probably this code won't work without modification): for k,v in pairs (self.modelTable) do for i = 0, v:CountSurfaces(), 1 do surface = v:GetSurface(i) mat = surface:GetMaterial() mat:SetShader(shader) shader:SetVec4("ex_color",self.color) mat:SetColor(self.color) self.modelTable[k] = nil end end
  23. As I said, you should take a look at the objects on your map and the scripts they have attached!
  24. I am pretty sure, the problem is coming from a LUA script of an object in your map, not from C++. That script has probably a world render or update hook, where it tries to access that variable.
  • Create New...