-
Posts
23,504 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by Josh
-
-
-
Like I said, it seems rather high.
-
I think deferred rendering is much more straightforward and simple. Lighting in forward renderers is always a hack. People complain about transparency lighting problems, but with forward rendering you NEVER have correct lighting.
-
I recently fixed a bug where the editor would not show the map as changed after modifying terrain, so unless you saved it your changes would be lost. This has not made it into the current build yet.
-
It isn't slow due to physics. It's slow due to the projected shadow rendering. Though that still seems excessive.
-
Good idea.
FYI:
vec4 color = vec4(entitymatrix[0][3],entitymatrix[1][3],entitymatrix[2][3],entitymatrix[3][3]);
-
Will check it out, thanks.
-
It should not matter. It should even be safe to delete them within a collision callback, now.
-
It was easy to get it to compile, but all I've got right now is a blue screen, so I am talking to Canonical about the driver situation in 13.10. I have someone else who is going to handle the remaining GTK stuff, which is the real grunt work, but this part is something I have to stay on top of. Also writing the GL4 renderer right now.
-
This is a very difficult situation because there is no way to detect what vertex attributes exist, and ATI cards on Mac always put out this warning if a non-existent attribute is set.
-
I understand this is a feature that will make life easier (and I want it ASAP, too) but there are over 300 Linux users who expect to have Leadwerks running on Ubuntu in December.
-
I really think that is the answer. That is the command the Map::Load function calls.
-
I love the style. Together with the reusable elements, it provides a consistent theme and allows a non-expert level designer (like me) to create compelling scenes.
-
Thank you. It is possible something is funky here.
-
You won't need to use WINE at all, soon enough. I'm building it to run natively on Linux.
- 1
-
Terrains render a series of repeating patches (for LOD levels) and render the area around the camera dynamically. The height date is stored in a 16-bit luminosity texture so a 4096x4096 terrain can be fit in just 33 mb of memory. If this were a model, the memory usage would be hundreds of megabytes.
So the advantages are:
- They render faster.
- They use less memory.
- They render faster.
-
Yes, this was something I did fairly recently.
-
Need some inspiration? Here are some physics puzzles from different games:
At 9:25 a box is blocking the engine from moving:
Turn two wheels to open a door:
http://www.youtube.com/watch?v=awbiL7He-pc
At 8:17 the player turns a wheel to move a crane and bridge a gap so they can get across:
At 2:00 various gears are assembled to make an engine:
Other ideas:
- Turning electricity on and off to make an area passable.
- Controlling a crane to move objects around.
- Running through a Halloween horror machine and dodging moving spinning blades.
- And of course, your own off-the-wall ideas that go beyond this.
The best approach is probably a simple idea with good execution.
- 1
- Turning electricity on and off to make an area passable.
-
Try Entity::SetShadowMode(Light::Dynamic)
-
This should occur every single physics update. The trigger will keep the entity awake and keep firing until it stops colliding.
-
Camera picking is a different overload, actually. There is an internal Entity::Pick command used by all the pick routines.
-
Are there any messages in the console like saying it failed to copy a specific file?
-
You are correct. Will fix.
-
That is quite possible...fixed for the next build.Maybe you really only forgot to save manually since the editor does not mark the map-file as changed as soon as you change anything on the terrain. You can see that at the asterisk in the titlebar beside the filename.
- 1
Models based level design
in Game Artwork
Posted
CSG modeling isn't the best for advanced artists, but it allows those of us who aren't expert modelers to quickly sketch out a map.