Josh
-
Posts
23,145 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Blog Comments posted by Josh
-
-
That's a definite probably.
-
It is.
I think Lua may be faster in L3D because the binding with C++ will probably be a lot more efficient than what we are doing now. Don't have any numbers to back that up, but it's just my guess.
-
Won't the shadows pretty much still have to be baked though? Isn't that a limitation of the hardware?
The capabilities are about the same as the Source engine, so you use lightmaps together with projected shadows. I've done these in the past, so it's easy for me to do.
-
I meant the second thing, but the "somewhat usable" qualifier raises doubt.
-
Is it really? I didn't know that.
-
Well said. This way programmers and designers can work together. The programmer writes logical scripts and the designer makes them do interesting things in a particular map.
-
Yes, that idea was ripped shamelessly from 3ds max.
-
I've considered that, but the 2D views are actually rendered straight to the back buffer. Also, not all supported hardware the engine runs on even support render-to-texture!
Now you get an idea of the constraints I deal with. -
CSG brushes will be saved into the map, or you can save them as prefabs, or convert them to models, or convert them to physics shapes. But normally, CSG brushes will be considered to be unique geometry for a given map.
I haven't thought about how much CSG commands will be exposed. Probably everything, because I am building it into the engine anyways, and I have to access it all from the editor.
Most days my progress is something like "that thing that used to crash the program no longer causes a crash" so I don't know if that is very interesting.
-
Probably because Blender isn't rendering a lot of post effects and lighting each frame.
It's not any slower than the redrawing in the current editor, but given the choice I'd like to keep the program feeling light and as responsive as possible. There's a subtle difference you feel when a program starts fast, closes fast, and resizes fast. Not sure why it makes a difference, but it feels better.
-
That's what I meant by "XOR drawing". GDI has some functions to draw a negative brush, which is what you are probably thinking of.
-
Another common technique is to overlay an XOR drawing and only resize the stuff when the mouse is let go, but that doesn't work for window resizing, and is Windows-specific. It's not a big thing, but I thought some of the programmers might be interested in what I found.
-
It's possible to just drag the four viewports around as you need, so you can make it 2 views or just one. However, with a complex scene I always find I need three 2D views so I can see what the scene geometry really looks like. This editor is being design to work as a complex level designer, not just a tool to drop some models in a scene, so the rules are a bit different from the last editor.
-
You can select the top-level directory, enable the recursive option, then enter a search term in the filter box, and the results will be filtered pretty near instantly. If you want to view all materials, for example, type in "*.mat" and hit enter.
-
Thanks to Lazlo for bringing this to my attention and making me think about this.
-
.thumb.png.930e14f6185274fc318c83d22a72a188.png)
Leadwerks Software Announces .NET Support
in Ultra Software Company Blog
A group blog by The Ultra Software Team in General
Uploaded.
-
Those are quite good, thanks!
-
Well, maybe they need a good engine to make games with first.
I honestly don't see what the fragmentation issues are about. More than 75% of Android devices will run OpenGLES 2.0, so they either comply with the spec, and will work, or they don't comply with the spec, in which case there's nothing I can do. OpenGLES is pretty simple compared to full OpenGL, so I think it won't be a problem. Even at the start of this year, only 50% of devices were 2.2 or better, but 2.2 gained 25% in 7 months.
We'll ignore the decreasing share below 2.2, and don't need any of the features in versions beyond that.
-
It's a challenge to handle user input on mobile devices, because they are so different from a computer. The iPhone version considers screen touches to be mouse hits and movements, so by default you get a reasonably consistent control scheme. Of course, on a PC you can move the mouse position, and on a touch device you cannot forcibly move the user's finger to a given position (yet
).I found an event queue was necessary for more advanced input like screen rotation and multitouch input, so if you need to get that info, the events are available to you.
-
Oh my Oh my.... Besides buying a MAC I now must by a IPhone
Don't forget the iPad.
-
Perhaps Google's +1 feature as well
Don't they have a simple PHP link you can use, instead of embedding a scripted item into your site?
I can see how it could catch on quickly if it's linked to SEO. Everyone will add one overnight to avoid being left out.
-
It's not just an OSX thing... and shouldn't the slash be the other way?
I can never remember which is which. The engine automatically corrects your paths.
-
I don't think iOS even allows you to render in an inactive app and eat up the battery.
On OSX and iOS, I'm using an Objective C entry point that calls the C++ main() function. So you can just write your program in plain C++ and not worry about Objective C, except for the default setup code just to make it work. There will be a "Project Wizard"-like dialog in the editor that will create the starting project for you, so you never have to touch any Objective-C yourself. Of course, a pure Lua app bypasses all of that altogether.
-
Looks great, shame there is no way of getting the Leadwerks love on WP7, im currently writing games for that platform.
It all depends on whether they allow C++ code on Windows Phone 7. Requiring C# only is suicide for their platform. Both Apple and Google realized already programmers don't want an "easy" programming language if it means they have to rewrite their whole program for one platform.
Now you get an idea of the constraints I deal with. 
.thumb.png.930e14f6185274fc318c83d22a72a188.png)
).
Entities and scripts
in Development Blog
A blog by Josh in General
Posted
An "actor" is a script attached to an entity, with a set of properties. Each actor has it's own set of variables in Lua that don't interfere with each other. You can have multiple actors, even actors of the same type, attached to one entity, and they are each in their own "space". In the flowgraph, you will actually be looking at actors, not entities.
To you and me, it's trivial to just write exactly what you want a script to do. To 99% of the potential market, programming is an utter impossibility, but they can attach a few behaviors to an entity and adjust some settings. It allows game development through visual trial and error.
Good eyes!
On one hand, this seems like a lot of work just to allow designers to do things without code that programmers can easily do. On the other hand, this means you can code a few scripts, give them to a designer, and let them make some game maps for you with interesting variations of the gameplay mechanisms you programmed.