-
Posts
24,629 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Downloads
Everything posted by Josh
-
Okay, I have Facebook and Twitter buttons working now. These reference the bit.ly link, which contains your referral URL. Every time you repost content you increase the chances someone will come across it and become a new customer. If you look at the lower-right corner of a page after you click an affiliate link, it should show "RID: " followed by your user ID. That's how you know it's working.
-
It actually contains the current URL in a PHP argument. The link first goes to the referral system, and then it forwards the user to the specified URL. I'll try to get Facebook and Twitter share links working. I have to run the URLs through a link shortener so they'll work.
-
We are running a promotional campaign for the next 90 days during which the Leadwerks referral system will be active. You will see some share icons in the website header on some pages on the site. Clicking any of these buttons will share the current page you are viewing, with your user referral ID embedded in the link. When a new person clicks on your link to visit the site for the first time, a cookie will be saved with your referral ID. If that person eventually makes a purchase on Leadwerks.com, you will receive 10% of the sale price of anything they buy. You can withdraw your account balance every time it reaches $20 or more. A Paypal account is required. You can share videos, images, blogs posts, and other user-generated content throughout the site. You'll be promoting your fellow developers' work, helping spread the word about Leadwerks, and you may even earn some money. One easy way you can earn sales is by putting a link to your profile in your signature on other forums. Please don't spam forums or post in competing products' sites. This system has just been implemented, so please be patient. I'd rather not have everyone go out spamming the world with links until we have the 2.43 evaluation kit released.
-
There actually is a forum topic automatically created for most file categories, and a link to the forum topic is on the file page.
-
Leadwerks developers can now submit their own Leadwerks.com banners and have them appear on our site. -Banner images must be 980x128 pixels in size, in JPG format, with 10% compression (high quality). -Your profile will be linked to from the small box in the upper right corner of the banner. -The title you submit will appear in the URL popup title. -Banners will appear in the rotation after they are approved by the staff. -If we have used one of your gallery images, feel free to resubmit it so you can get it linked to your account, and get full credit.
-
Leadwerks.com launches new community features
Josh posted a blog entry in Ultra Software Company Blog
Leadwerks.com now features a video gallery where our members can post movies of their games made with Leadwerks Engine. Instead of slowly uploading a huge video file, you can simply enter a YouTube video ID to submit movies. Check out some of the cool videos like Legos falling over to a techno soundtrack, fly through floating islands in Aerora, and of course there's Dave Lee's excellent Chernobyl Exclusion Zone. We've also created a random rotating banner image in our website header. Leadwerks developers can now submit their own Leadwerks.com banners and have them appear on our site. -Banner images must be 980x128 pixels in size, in JPG format, with 10% compression (high quality). -Your profile will be linked to from the small box in the upper right corner of the banner. -The title you submit will appear in the URL popup title. -Banners will appear in the rotation after they are approved by the staff. -If we have used one of your gallery images, feel free to resubmit it so you can get it linked to your account, and get full credit. We hope these new community features give our users even more ways to interact and have fun making games. -
Awesome! Where do I buy?
-
I've finally got the Asset Store looking the way I want: http://www.leadwerks.com/werkspace/files If you are a content author, get your files ready for July 25, when I will announce the launch. To apply to the merchant program, visit this page: http://www.leadwerks.com/werkspace/page/merchants There will be some promotions going around for new licensees to get free store credit, so that means people will be spending in the store to buy your assets. If you have any questions, just post here or PM me.
-
Leadwerks Engine 3 will run on your computer. Leadwerks Engine 2 will not.
-
I don't think there's anything I could even do to support it. LE is just a DLL, and I think this needs to be integrated into the main executable. I don't think it has to hook into the renderer in any way. I think it can be set up without modifying your EXE.
-
I don't know what is involved in setting up a program to run on Steam, but I imagine it is pretty easy. There's even been some Blitz3D programs on Steam, so it can't be too difficult.
-
I don't think so, I don't even know what those extensions do. Anyways, it's fixed now.
-
I wouldn't call LE3 even in the "pre-order" stage yet. There's no product to use at this point, even in a limited manner.
-
You're going to laugh when you see the fix. This is for version 2.43. I don't know if this will work for the evaluation kit. Find this line, around line 97 of "terrain.frag": height = vertexposition.y; Change it to this: height = texcoord0.y;//vertexposition.y; There is NO REASON I know of this should make any difference, because they are the same value, but through trial and error I found this worked. The shader does not give any warnings and works fine on NVidia and older ATI drivers, so I have no idea what is wrong with their drivers, but this fixes it on my test card.
-
ATI's drivers magically stopped working in an update they put out. There's no errors, no warnings, the shader just doesn't display right. A single texture lookup in the fragment shader screws up the vertex positions.
-
Terrain and models are two different things. Rendering the whole terrain using tessellation to handle the LOD isn't a good idea. Everything else here makes except their culling recommendations don't work. Just because a patch is back-facing does not mean a resulting triangle on it will be! Just because a patch is out of the frustum does not mean a triangle that results from subdividing that patch will be. It may be possible to add a buffer distance equal to the maximum tess extrusion distance, in which case culling in the shader would work. But not for terrain.
-
It certainly will work with VB.NET but it's up to you to retrieve the function pointers from the DLL.
-
I can never remember which is which. The engine automatically corrects your paths.
-
LE3 will initially support Windows, OSX, and iOS (iPhone and iPad). Android support is planned on following this.
-
Sorry, I didn't realize the image was linked from the gallery. I removed the image in the gallery because it didn't belong in the LE2 gallery. You can attach the image in your post if you like. They chucked a single vertex buffer at the GPU, which is the worst way you can render terrain. LE2 renders a set of instanced patches, and uses the displacement map for the height info. If you draw a single quad and tessellate it, you will lose the ability to show and hide sections of the terrain, even areas behind the camera. That means the tessellated approach will have to process maybe 3-4 times as many vertices. Because the tessellation pipeline is completely programmable, the hardware can't anticipate and cull offscreen patches. That discrepancy won't be apparent when you are rendering the whole terrain onscreen at once. Now you can still use tessellation on terrain patches, and have the speed of our existing terrain rendering, along with fine surface geometry detail. This reinforces my original statement, that tessellation is good for surface detail and not really useful aside from that.
-
Leadwerks Engine 3 is being coded in C++. As far as I know it is impossible for Leadwerks Engine to run on XBLA because they do not support C++ programing.
-
I already have it implemented. That image is so incredibly misleading. They are comparing a tessellated terrain to the most inefficient possible method of rendering terrain, and dismiss the displacement map in their memory totals The old ATI tessellation extensions are not the same thing as OpenGL4/DX11 tessellation shaders.
-
I'm working on this issue today. There's nothing wrong the the shader, but I'm going to have to find a way around this since ATI isn't going to fix their drivers. I wish they would just roll them back six months and stop releasing updates.
-
A few weeks ago, I was getting pretty nervous about all the known unknowns in going cross-platform with the Leadwerks Engine 3 code. All my libraries and languages are platform-agnostic, but there's always going to be small issues, and I wanted to get those worked out while the code was still malleable. Here's a few things I found. -OSX file paths don't have a drive letter, so the only way to specify a relative path is to add ".\" to the beginning. This had some significant implications for the asset reloading system. -iOS file paths are case-sensitive. -iOS projects require that all external files included in the project as a resource! Good thing the editor will be able to gather these up and generate a project automatically. -OSX child windows can't have their own menus. This means I have to make sure the tool windows in the editor have a complete toolbar for every function you might need to use. -OpenGLES doesn't allow shader uniform initializers. Although I rely on these to define default uniform values in the editor for the visual controls, the editor is actually never going to be running OpenGLES, since it's for embedded systems only. That's odd but convenient. -The default OSX default font is Lucida Grand 13 pt, a bit larger than the default Windows font, which required more space on some interface elements. -The minimum button dimensions on OSX you should use are 31x31. Otherwise those rounded corners won't have enough space to display properly. -There is no consistent OpenGL compressed texture format. Windows and OSX support DXTC, and iOS uses PRVTC. This is annoying, because it means uncompressed RGBA is the only cross-platform texture format. However, I think we can do an automatic PRVTC compression in the editor's "Publish" step for iOS, on DXTC compressed textures only. I don't even know if PRVTC format will even appear in the editor. -Aside from deferred rendering, OpenGLES2 can do pretty much anything OpenGL3 can. Pretty amazing potential here. Here's the current editor, showing the texture, material, and shader systems fully working together to make this skybox material. It presently works with OpenGL 3.2 on Windows, and OpenGL 1.4 on Windows and OSX. OSX Lion comes out this month, at which point I hope to have the GL3 renderer running on Mac as well: Android is the platform I am least worried about, in terms of initial implementation. I'm not sure if the NDK supports pure C++ programming yet, but that seems to be the direction they are heading in. The OpenGLES implementation for iOS should work the same on Android devices. iOS was definitely that hardest implementation to write, and it's not nearly complete, but I've seen enough I am confident we can become platform-agnostic with our code. I'm going to take a stab at the ATI terrain bug this afternoon. I don't think I'll get it fixed today, but it looks like ATI isn't going to fix their drivers, so I need to find a way around it.
-
Then they aren't potential customers. Definitely. You want your major software applications to be an ongoing relationship so that your input matters. I'm sure you've had a piece of software you used that stopped producing updates even though you would have paid for one. Unlimited expansion doesn't happen. I'm planning on an OpenGL 1 / Lua "indy" version for free or cheap. Generally, you want to segment your market so that you can get the most you can out of each type of customer. Some want all platforms and will gladly pay for them all, while some want a cheaper solution on one platform. I also want to have data on which platforms devs actually pay for, so I know what they value. I'm leaning towards making Windows/OSX the base package and then having add-ons for mobile platforms. This also means when a new mobile platform comes along, the addition of support for it can be self-funding; it doesn't rely on attracting new customers through added benefits.