Unofficial, alpha 19 weekly build
Unofficial, alpha 19 weekly build
The unofficial, alpha 19 leaked build is here!
A "leaked build" is when John and I literally grab the latest SVN build and package it up for you guys. It has a ton of known bugs, so don't worry if it doesn't work for you. It is not condoned by David, Phillip, and Aubrey, but we want to keep you guys in the loop and give you stuff to play with regularly! Please report bugs in Trac! http://trac.wolfire.net/spf/overgrowth
New in this version: (see blog)
Also, press P to toggle wireframe stuff. Press 8 and 9 to toggle the Rabbot. Press ` for the console. Type Console.help() for the console commands.
Press b to spawn a physics box, right click to drag it around.
We are testing out BitTorrent again this week! Please let me know how that goes.
Windows: (direct) (torrent)
Mac OS X: (direct) (torrent)
Subscribe to the dev blog!
Ryan Gordon is in charge of the Linux build. No word on that yet -- he will probably wait until we are further along.
Note! No PPC or 10.4 Tiger support at the moment -- we are waiting on Chrome for these. We are not sure when this will happen.
A "leaked build" is when John and I literally grab the latest SVN build and package it up for you guys. It has a ton of known bugs, so don't worry if it doesn't work for you. It is not condoned by David, Phillip, and Aubrey, but we want to keep you guys in the loop and give you stuff to play with regularly! Please report bugs in Trac! http://trac.wolfire.net/spf/overgrowth
New in this version: (see blog)
Also, press P to toggle wireframe stuff. Press 8 and 9 to toggle the Rabbot. Press ` for the console. Type Console.help() for the console commands.
Press b to spawn a physics box, right click to drag it around.
We are testing out BitTorrent again this week! Please let me know how that goes.
Windows: (direct) (torrent)
Mac OS X: (direct) (torrent)
Subscribe to the dev blog!
Ryan Gordon is in charge of the Linux build. No word on that yet -- he will probably wait until we are further along.
Note! No PPC or 10.4 Tiger support at the moment -- we are waiting on Chrome for these. We are not sure when this will happen.
Re: Unofficial, alpha 19 weekly build
Btw, I am still uploading the builds. Our internet is particularly slow today so it should take about 30 minutes to one hour from now to finish.
-
- Posts: 146
- Joined: Sun Jan 18, 2009 6:15 am
- Location: Damn it, I swallowed the blue pill again.
Re: Unofficial, alpha 19 weekly build
ok. I can wait... sorta.
Re: Unofficial, alpha 19 weekly build
Alright, it is good to go!
Re: Unofficial, alpha 19 weekly build
Physics in the engine? Wow, if you guys manage to optimize all this somehow, this is going to be an awesome engine. I wonder how long it will take before people will be building physics-compliant houses and then making them explode.
Re: Unofficial, alpha 19 weekly build
Yeah i cant wait for the exploding housesEndoperez wrote:Physics in the engine? Wow, if you guys manage to optimize all this somehow, this is going to be an awesome engine. I wonder how long it will take before people will be building physics-compliant houses and then making them explode.
Re: Unofficial, alpha 19 weekly build
Alright, a quick review as usual for the Mac version:
The 'Custom' Folder hasn't been added yet. I'll try to finalize that format this week so maybe with a20?
As with a18 the world loads with wire-frame showing Bounding boxes for groups are cool... but they don't encompass the bounds of the objects as the name seems to suggest... and even if you delete the group, they still magically appear after the contents has been deleted even when no objects exist anymore, only groups, the former group's bounding box remains and cannot be deleted.
Same thing happens when you do any other modification, like duplication, and then try to undo it in this image the blue bounding box belongs to the group on the left, and the left group can be modified by clicking and moving the right box or the group itself. again, after any transformation, undoing does -not- affect the bounding box, but -does- affect the actual grouped objects.
When I tried deleting more than a few objects at a time the program crashed. selecting all and deleting will definitely trigger it every time, but sometimes after deleting a handful of items deleting only one will cause a crash. It seems to be random which item to be deleted causes the crash.
Plain old Option+drag (no control, shift, etc.) still doesn't duplicate the object on mac.
Rotation now snaps correctly, but only in 30° steps, meaning rotating at 45° exact is impossible. I think 45° is more useful than 30, maybe you could add an irregular step so it's 0,30,45,60,90 etc.
Console is wonderful, but really cuts the Framerate and typing in it seems sluggish as a result.
For example with a normal framerate of about 70, it drops to 40 when visible and 10 when selecting text or continuously typing. There also seems to be some input lag ontop of that.
Autocomplete does not provide the complete syntax. for example Console.help() is autocompleted as Console.help. It should include the () and when you accept the suggested autocompleting it should place the cursor inside the () to allow you to quickly enter parameters.
When the console is open keystrokes for the world should be disabled. As it is now, copy and paste as well as select all still seem to affect the objects in the world as well as whatever is being typed in the console.
Using tab you can switch through suggested commands. will post a list of all of them soon.
Sound is working nicely, though an option for disabling the shaking/sound in editor mode would be nice to have in the misc. panel.
Physics are great to see, and hoping for much more optimization there.
right now the framerate drops linearly with each object added, at about 100 objects the framerate drops bellow 5 and thus the editor becomes unusable.
Rabbot does not yet Interact with the objects though.
Of-course because both multi-selection and spawning cubes are now set to b you can't do one without the other, so every time I try and select multiple objects I create physics objects that eventually kill the frame-rate.
While testing the physics I experienced a few total program crashes, no error message, just quit, so it seems to be a bit buggy.
Apart from that though physics seems solid, and I didn't encounter any physics bugs, even when dropping them on and moving them into stationary objects
Lastly, since this might be specific to my graphics card (Mac with Nvidia 9600M GT 512 Vram) here is a video of a Shader bug with the object called pillar1.xml which has been bothering me for a long while:
http://jo-shadow.com/Public/Johannes/Mo ... r_bug.html
As you can see the pillar is completely flat shaded until you get close to it, and then only the top part is 'shiny' as I think it should be. This has been the case since the first alphas that had a usable editor. This type of bug only seems to occur in this one object. haven't seen it on any of the other rocky objects.
The 'Custom' Folder hasn't been added yet. I'll try to finalize that format this week so maybe with a20?
As with a18 the world loads with wire-frame showing Bounding boxes for groups are cool... but they don't encompass the bounds of the objects as the name seems to suggest... and even if you delete the group, they still magically appear after the contents has been deleted even when no objects exist anymore, only groups, the former group's bounding box remains and cannot be deleted.
Same thing happens when you do any other modification, like duplication, and then try to undo it in this image the blue bounding box belongs to the group on the left, and the left group can be modified by clicking and moving the right box or the group itself. again, after any transformation, undoing does -not- affect the bounding box, but -does- affect the actual grouped objects.
When I tried deleting more than a few objects at a time the program crashed. selecting all and deleting will definitely trigger it every time, but sometimes after deleting a handful of items deleting only one will cause a crash. It seems to be random which item to be deleted causes the crash.
Plain old Option+drag (no control, shift, etc.) still doesn't duplicate the object on mac.
Rotation now snaps correctly, but only in 30° steps, meaning rotating at 45° exact is impossible. I think 45° is more useful than 30, maybe you could add an irregular step so it's 0,30,45,60,90 etc.
Console is wonderful, but really cuts the Framerate and typing in it seems sluggish as a result.
For example with a normal framerate of about 70, it drops to 40 when visible and 10 when selecting text or continuously typing. There also seems to be some input lag ontop of that.
Autocomplete does not provide the complete syntax. for example Console.help() is autocompleted as Console.help. It should include the () and when you accept the suggested autocompleting it should place the cursor inside the () to allow you to quickly enter parameters.
When the console is open keystrokes for the world should be disabled. As it is now, copy and paste as well as select all still seem to affect the objects in the world as well as whatever is being typed in the console.
Using tab you can switch through suggested commands. will post a list of all of them soon.
Sound is working nicely, though an option for disabling the shaking/sound in editor mode would be nice to have in the misc. panel.
Physics are great to see, and hoping for much more optimization there.
right now the framerate drops linearly with each object added, at about 100 objects the framerate drops bellow 5 and thus the editor becomes unusable.
Rabbot does not yet Interact with the objects though.
Of-course because both multi-selection and spawning cubes are now set to b you can't do one without the other, so every time I try and select multiple objects I create physics objects that eventually kill the frame-rate.
While testing the physics I experienced a few total program crashes, no error message, just quit, so it seems to be a bit buggy.
Apart from that though physics seems solid, and I didn't encounter any physics bugs, even when dropping them on and moving them into stationary objects
Lastly, since this might be specific to my graphics card (Mac with Nvidia 9600M GT 512 Vram) here is a video of a Shader bug with the object called pillar1.xml which has been bothering me for a long while:
http://jo-shadow.com/Public/Johannes/Mo ... r_bug.html
As you can see the pillar is completely flat shaded until you get close to it, and then only the top part is 'shiny' as I think it should be. This has been the case since the first alphas that had a usable editor. This type of bug only seems to occur in this one object. haven't seen it on any of the other rocky objects.
Re: Unofficial, alpha 19 weekly build
It seems like a lot of people are getting strange shader glitches still-- we are going to have to look into that
Re: Unofficial, alpha 19 weekly build
This is amazing. The map editor is turning into a sandbox style game itself. I would have payed 30$ for the editor alone.
Waiting for:
constraints
welding
scripting
Just think, building a huge working catapult to fling rabbot about!
Oh and of course them sexy dynamic shadows! I'm a graphics whore, what can I say.
Waiting for:
constraints
welding
scripting
Just think, building a huge working catapult to fling rabbot about!
Oh and of course them sexy dynamic shadows! I'm a graphics whore, what can I say.
Re: Unofficial, alpha 19 weekly build
That's just a different cubemap reflection.Shader bug with the object called pillar1.xml which has been bothering me for a long while:
Anyway, the shader code is quite bad.
From the same cubemapobj fragment shader:
Code: Select all
vec3 normal = normalize(vec3((normalmap.x-0.5)*2.0, (normalmap.z-0.5)*2.0, (normalmap.y-0.5)*-2.0));
Code: Select all
vec3 diffuse_map_vec = normalize(mat3(obj2world[0].xyz, obj2world[1].xyz, obj2world[2].xyz) * normal);
diffuse_map_vec.y *= -1.0;
Same should be here:
Code: Select all
spec_map_vec = normalize(mat3(obj2world[0].xyz, obj2world[1].xyz, obj2world[2].xyz) * spec_map_vec);
spec_map_vec.y *= -1.0;
EDIT: Also the rabbot's arm is missing. I had those random problems with body parts when I had some bad code that used floating point numbers dangerously. I didn't initialize them. So look if you have something like that in your initialization code.
Also I'd like to know if you have that opengl device state caching already implemented in renderer's code.
Last edited by GDer on Tue Mar 24, 2009 3:40 pm, edited 1 time in total.
Re: Unofficial, alpha 19 weekly build
It could be, but we are doing it this way because then it works with the 3DS max default object space normal map shader, and so lets us check work sooner and overall make the workflow faster.Some kind of realtime axis changing when that could be preprocessed in textures.
I am not sure why you think we don't have a well thought out or good art style or that you feel our shaders won't work with the style we are going for. Our shaders, like everything else, are a work in progress.
We have a very clear art direction. What we have so far is largely based around making the shaders work with the art I am producing-- it is far easier to add a couple lines of code to the shader than it is for me to completely change my workflow.
Re: Unofficial, alpha 19 weekly build
Feel free to try to rewrite the shaders to be better! It will update them in real-time so you can see any changes.
However, all of the snippets you mentioned are like that for a good reason, as you can quickly find out by changing them and watching them fail. The lighting can't be preprocessed for each object, because then we can't share textures between objects, and the framerate will be demolished by texture swapping. We don't do the lighting in the vertex shader because it is based on the normal map, which is only accessible from the fragment.
However, all of the snippets you mentioned are like that for a good reason, as you can quickly find out by changing them and watching them fail. The lighting can't be preprocessed for each object, because then we can't share textures between objects, and the framerate will be demolished by texture swapping. We don't do the lighting in the vertex shader because it is based on the normal map, which is only accessible from the fragment.
Re: Unofficial, alpha 19 weekly build
Isn't there a way to convert a texture to a more optimized format before putting it in the game? Maybe the game itself could do it.It could be, but we are doing it this way because then it works with the 3DS max default object space normal map shader, and so lets us check work sooner and overall make the workflow faster.
I don't know, it just looks like some things just doesn't stick together. Like the icy shader on the blocks that are in the desert map. Or the stone-like detail map for terrains...I am not sure why you think we don't have a well thought out or good art style or that you feel our shaders won't work with the style we are going for.
If you just don't show the best of what you'll make, that's ok, that would be a good reason for me to wait when you say that the game is ready and not to think that there's a problem.
Ok, I'll try in my free time.Feel free to try to rewrite the shaders to be better!
And I don't ask you to do that. I'm just wondering why a piece of code in your shader isn't written differently... Anyway, you can't stop my graphics card even with a shader like this so CPU code optimization is more important.We don't do the lighting in the vertex shader
Re: Unofficial, alpha 19 weekly build
Lol at what seems to be a test platform for physics underneath the map.
Re: Unofficial, alpha 19 weekly build
Been there since a few alphasMoDFoX wrote:Lol at what seems to be a test platform for physics underneath the map.