- This topic has 94 replies, 3 voices, and was last updated 9 years, 3 months ago by
.
-
Posts
-
I already have an almost finished game on my harddrive.
I will release it as soon as all features needed are merged into the engine since it uses functionality from a game plugin. My plan is to make it possible to do anything you need in a Lua script without any native code involved. This does not mean that it will be impossible to do any native plugin and should make development faster and easier.
If you are curious: It is a kart racing game similar to STK or Super Mario Kart 64 😀
And I still need a name…
I see, sounds good. My plan is more of an action game from an isometric perspective. So what do you think, that would require? I guess since the characters have skeletons, will need multithreading and hardware skinning. and i found this -> https://software.intel.com/en-us/articles/optimized-cpu-based-skinning-for-3d-games
Multithreading is already implemented and just needs to be used some more. That’s for all games not just yours.
Hardware skinning will not be neccessary for your game since the isometric view implies that you have quite a distance between the camera and your scenery leading to the possibility of using lower polygon meshes and lower resolution textures. You don’t need super high quality characters if you plan an isometric perspective.
Btw: If you want to show your product you can always upload some screenshots 😀
Hmm, so if i have a like 20 characters, just multithreading will do the trick you say! Im doing only testing for now, but my plan is to do a commercial game with an Android and Ouya port.
Got some new question:
Do you look at other game engines code for inspiration?
Ive got the GPU pro books(pdf), do you want them?I don’t really look into other engines since most of them are proprietary anyways. Mostly I read the docs since they show how those engines are structured from an API perspective. I mostly read the original Maratis source code since no real docs exist and the code is the only hint on what’s going on in there.
Thanks, but you don’t have to send me those books 😀
If I need a book I usually buy it 🙂About your 20 characters: I found that the bottleneck is not the rendering pipeline but more the physics engine. I can render about 120 animated karts in my game at 100+ FPS without problems. What slows things down are all the physics calculations. Then again, I do have quite a beefy rig so you could have different problems than I have.
Another thing: Don’t optimize if the user experience is not harmed by not optimizing your game. Premature optimizations kill your game before it is even playable. Write your game and see how it runs. If it is too slow look where possible problems are and then optimize just those bottlenecks. Nothing more and nothing less.
Proprietary as the license permit it, i would say! 🙂 I also looked at the Maratis code, but my knowledge is small to understand it without comments. I looked at c++ a log time ago, since i was bothered with, whats this stuff “name::name, ptr->” at least i can read it. 🙂
The physics of Maratis are a little confusing since i miss the static/dynamic from the BGE engine. Maybe that should lower the physics, by setting them to static, the one you dont want to be movable, but just collidable. Yes, the optimization should be added later in development.
And some interesting articles to read:
particles-instancing, the website looks really good, dont know if you know about it.
http://www.opengl-tutorial.org/intermediate-tutorials/billboards-particles/particles-instancing/
Some useful shader stuff.
http://renderingpipeline.com/2012/06/photoshop-blendmodi-glsl/
http://mouaif.wordpress.com/2008/06/11/crossprocessing-shader/
http://mouaif.wordpress.com/2009/01/05/photoshop-math-with-glsl-shaders/Thank you for the links 😀
Static objects are simply objects which have physics enabled but no mass.
A static setting would not do it differently so there is nothing to optimize.
I have to add that I use a much higher physics precision than the default one.Well i was going to write on the Maratis forum, but will say that. The problem with the exporter is:
1 – the object must be at the center of the screen(0,0,0) or else the boundary will become bigger and the pivot away from the center of the object.
2 – you cant export more than one object at a time, for example, you could have a series of different objects and you want to export them at the same time, but with different names, different meshes.
3 – you may want to build directly the map inside the blender, but again the export will be one big mesh, but you want to select the objects in the editor after you exported.
I guess the first one is more critical, but im only saying. 🙂1) This behavior is intentional. It’s about exporting multiple sub-meshes which should have right position/rotation/scale in relation to each other.
2) You can export multiple objects as sub-meshes. The purpose of the mesh export plugin is not to build a level in Blender! You don’t need to automatically export every sub-mesh in a new file for building 3D objects to use in your game. Simply create a new Blender project for each new object.
3) is similar to 2): It is not the purpose of the Blender plugin to allow you building levels in Blender! It is just a way to import meshes made in Blender into the native level editor!
I don’t think that any of these are really bugs or problems. The Blender plugin does exactly what it was meant for: Exporting meshes from Blender!
Sorry if I sound too harsh. I don’t want offend you 😀
Things that really need to be fixed are problems with newer Blender versions concerning valid output of materials, animations and geometry. Since Blender likes to change the plugin API a lot it needs to be fixed regularly.
- You must be logged in to reply to this topic.