Any interest in Vivid2.0 OpenSource?
BlitzMax Forums/BlitzMax Programming/Any interest in Vivid2.0 OpenSource?
| ||
| I'm mainly developing the engine for my game, so I'm not all that concerned about making money off it, but I'm not entirely sure if there are many openGL coders here, or at least many who'ed be interested in taking part? Ignore the mess of TrinityOS, I'm talking about a clean (Non-modulized, so no mingW bs required atm) build with a few working examples(Including 3ds loader atm), shaders already supported(GLSL) and I'd document each part of the engine and indicate what needs done, etc.. It could be great to have a uber powerful engine coded by a bunch of coders...in fact, I can't see how an engine coded by one guy(me or anyoneelse) can better it! Any interest at all? |
| ||
| Here's a small example of the engine, incidentally, that creates a cube and loads a jeep. The engine is entirely OOP based. Local Gfx:Display = Display.Create(640,480,16,FullScreen) 'Create a cube. Local Test:Entity = Mesh.CreateCube( 5 ) 'Create a material Local Metal:Material = New Material 'Load it's texture Local Rough:Texture = Texture.Load("Metalic.Jpg") 'Add texture and assign material to cube. Metal.AddTexture( Rough ) Test.SetMaterial( Metal ) Local Man:Entity = FileIo.Load("SwordMan.3ds") '- 'Set both meshes to use vertex arrays. Man.SetRenderClass( VertexArray.Create() ) Test.SetRenderClass( VertexArray.Create() ) 'Create a batch renderer visualizer - This allows you to sort renders by material, regardless of surface/entity ownership.(Faaast.) Local Renderer:BatchRender = New BatchRender Renderer.AddEntity( Man ) Renderer.AddEntity( Test ) Renderer.SetCamera( New Camera ) Repeat Gfx.Cls() Renderer.Render() Gfx.Flip() Until Keydown(Key_ESCAPE) give or take a typo. |
| ||
| Ooh, yeah you know im interested. Although I might have to change that to something like: without comments cluttering it up - for me comments confuse the meaning almost: I imagine there will be lots of disagreements on the best way to code the interface, this seems pretty good to me. Perhaps we should design it and then make it (obviously the stuff youve already made will give a good head start) |
| ||
| I'd be happy to help... |
| ||
| Bot, yeah I know man, sorry for not sending it to you like I promised. Just sorting out a lighting bug before I do. Three people is probably enough to get things rolling in the kind of direction that will attract more people to the project... I'll probably start doc'ing the engine code tonight and see how it goes. Few comments on your design suggestions in the meantime bot, Local Gfx:Display = Display.Create(640,480,32,FullScreen) Local Game:World=new World Local Cam:Camera=Game.CreateCamera(Gfx) The batch renderer object is a sub class of the Visulizer set up. In essence it IS the above, only more flexible because it could be something like a octree, or a combination. I'm happy to discuss changes in termonolgy though. Visulizer sounds cool but it's not very describtive. Local Test:Entity = Game.CreateCube() A general 'game' class to simply things like the above seems fine though. Would make things easier to learn and would result in less cluttered engine classes. Local Metal:Material = New Material Metal.AddTexture( "Metalic.Jpg" ) wrong quote but screw it. In answer to your question, you can add as many textures as you like, the engine uses gl extensions for multi-texturing. Shadergen generates shaders correctly for multiple textures too. Bump-mapping is not supported yet, but shaders are in, so the hardest part is generating tangants. That needs to be done first. Test.SetMaterial( Metal ) Test.SetPosition(5,0,10) Local Man:Entity = Game.LoadEntity("SwordMan.3ds") Man.SetPosition(-5,0,10) I'd prefer to keep loading in the fileIO class, to leave room for extended classes with multi-threading support. I've already wrote a working threads library for windows, so this will happen for sure on at least one platform. Repeat Display.Cls() Cam.Render() Ah, well you can actually do Cam.RenderEntity( Entity) atm without needing a visulizer, but to render all would require a visulizer to be passed to the current camera presently. We can discuss if this is the best way to go, though, obviously. Display.Flip() |
| ||
| Fair enough. Yeah, i was kinda set on the idea of using worlds. If its basically the same as a 'BatchRenderer' thats fine. The only functional differences between my 'world' and your 'visualizer' are that with a world you add objects directly to it rather than creating objects and then adding them to it. Also, worlds can have multiple cameras. With your system as I have seen it so far, It would be pretty hard if you wanted to have, say a rear-view mirror cam without moving the main camera around all the time or adding every object to the rear view mirror's renderer. So, the only things im interested in changing now are possibly the ability to give strings for some of the functions that take handles for textures, entities, etc. Oh, and: 'Set both meshes to use vertex arrays. Man.SetRenderClass( VertexArray.Create() ) Test.SetRenderClass( VertexArray.Create() ) You could still be able to do this but if you left it out the engine would pick the best method based off the card, the object (animated/not - you could add in the ability to mark that a specific static meshs will be modified every frame). A general 'game' class to simply things like the above seems fine though. Would make things easier to learn and would result in less cluttered engine classes. Game is the world the cube is being added to. I couldnt call it world because thats the name of the type... A way to load and add something to the renderer in one call would be good though. |
| ||
| I would help, but I know nothing. If you need any busy-work done, though, such as final docs, I can give that a shot. |
| ||
| You could still be able to do this but if you left it out the engine would pick the best method based off the card, the object (animated/not - you could add in the ability to mark that a specific static meshs will be modified every frame). The problem is, render classes are extended from from the renderbase class. I.e they are plugins. So it's not entirely certified there will be only one vertex array implentation. So, although it's easy enough to have a default method, there's no real way of determining a 'best' method. Game is the world the cube is being added to Oh, misread. Well in that case we can't really do that, because visulizers, as above, are engine plugins, and are not integeral. You can remove them from the engine and it'll run. add new ones etc. Mostly semantics at this point anyway, it's early enough to streamline these aspects in other ways anyway. -- Pickle, thanks, I'm sure I could do help with anything involving use of the English language :) |
| ||
| if you post it people will be interested, if they aren't well whats wrong with them :P |
| ||
| Code my engine. Didi-mow! :) |
| ||
| So, although it's easy enough to have a default method, there's no real way of determining a 'best' method. Well, some methods will not be supported by some graphics cards though, and if they are hard coded it will fail. I would have a abstract function in the base type for the methods called something like "Works()" or "Supported()", which determines if this particular method is supported by the graphics card. So, if Supported() returns 0 then it will not use the method, or return an error. So, some are better than others because they actually work :). On top of this many methods are obviously better than others. For instance, vertex buffers>vertex arrays>glBegin(GL_TRIANGLES), as far as speed for static meshes goes. For dynamic meshes vertex arrays are better than vertex buffers, so in order to determine this the user must inform the engine if a static mesh they loaded will change alot - perhaps through a flag.Maybe a function in each type like Fitness#(Dynamic=0) which returns an arbitrary value, based on what other methods return. For instance, for static meshes, just passing vertices to the card would be 1, vertex arrays 2, vertex buffers 3. Other methods could insert themselves between or around these values. In the beginning, probably on the graphics call, it will decided on the optimal method for static or dynamic meshes. This technique for selection of defaults could of course be applied to other things like how to do dynamic enviornment maps - shader or cube maps. As for the actual method of doing this, before any user code is run, each type registers itself by calling a registration function with one example of itself created through new. I believe that the engine can take these examples and call the functions mentioned above, and more importantly, create. This allows it to arbitrarily select a plugin. |
| ||
| Yeah, that is possible. Presently the loader system(Also plugin based) does exactly that. Each loader calls a method in the base loader class to register it's self.(the loader's new method defines the extension that invokes it), but the renderClasses do not have a registration based system. But if we did as you suggest then we can do exactly that, let the engine pick one using supports. Probably want a Specialized flag in there, so it doesn't pick any renderclasses that are for special circumstances. - Just one final bug to fix and I'll send it to you, then hopefully put it online to get the ball rolling. |
| ||
| Ok, I fixed the final known bug and have send you it Bot. Let me know if you have any problems. |
| ||
| hey Ant... if this thing is working, or if you want to see what works and what doesn't, on the macintosh side, send it to me, and a list of what you want looked at... mailto://mikey102@... --Mike |
| ||
| id be intrested to see it as well i have a couple linux and windows machines I can run it on |
   |