Sanctus

Figured it out. It is indeed a bug but I managed to make a hack. I'll make a report when I'll have the time.

Hey guys. So I was continuing to work on my project and I got to the part where I save the maps that I create in my own editor. There was a bug that made heightmaps flip on some axis or something but now that got fixed with 2.32. Still when I save my alpha map with dds format (for png,tga,etc it said that there is no loader though on wiki it says that there are) and load them back I get very squared textures just as if all the vertices of a square of terrain have the same blend value. Look at the picture below to understand better what's happening. Does it happen to anyone else?

Take this from a C++ elitist: BlitzMax is awsome. I programm anything related to leadwerks in it and I never use the sandbox. It's easy to set up and start programming. I also tried DBPro and all that ****. Glad I didn't buy anything. You will see that Leadwerks also has small bugs (which is normal thinking it's made by just one guy) but you will get fixes for them and nothing will actually stop you from working. DBPro as I remember it had tons of bugs with some that were actually big.

This actually happens because of blitzmax. When I was making Mahjongg I noticed this. I noticed that if you printscreen, alt-tab,paste to paint it will be black, but alt-tab again and printscreen again and the paste will be good. Didn't test it with Leadwerks but it's based on Blitzmax internals and also uses OpenGL so it should be the same.

I guess file->New->Lua File then you save and compile (or just compile not sure). But that depends if you want to do some real work with blitzmax or c++ or just fool around in the editor.

Here is my style of multi-level games: Type Tapp Global ResX:int Global ResY:int Global Depth:int Global FullScreen:Byte Global game:TGame Function Start() End Function Function Run() End Function Function LoadConfig() End Function Function SaveConfig() End Function Function LoadResources() End Function End Type Type TGame Field screen:TScreen Method Initialize() End Method Method Draw() End Method Method Update() End Method() End Type Type TScreen Field elementList:TList 'by element I mean GUI objects Field objectList:TList 'Basically everything that can be updated/Drawn Field World:TWorld Field Camera:TCamera Method Initialize() End Method Method Draw() abstract Method Update() abstract End Type Type TGameScreen extends TScreen Field Level:TLevel Field player:TPlayer Method Draw() End Method Method Update() End Method End Method Type TLevel Field basePivot:TPivot 'A lot of other info about the level' Function Load:TLevel(path:string) End Function End Type I hope this gives you an idea. Basically that's why I'm saying people shouldn't start big projects before doing at least one normal casual game where they can learn these things.

Chillout! I'm sure there will always be support for Blitzmax. Even in LE3.x

You know why? The guys who manufacture them use old parts or parts that have problems just to get them cheaper(why do you think they are 25-50% cheaper?). I know this from a guy that worked on the assembly line. Frankly I'm looking at Asus G51J. A bit expensive but freaking hardcore in terms of performance and it's not bloated like those from Alienware.

Okay while I programm in C++ for the most I just have to say the you are an idiotic freak to say "Nobody uses Blitz for professional development." People got more money from blitzmax and blitz3D than your life will ever be worth. I had a job to do a clock with nice graphics. I did that in like 2 hours and I got around 250$. Look at Gray Alien games. The guy there programs his games in blitzmax and now works at Bigfish games. Blitzmax supports a lot of nice features (language-wise) and even if it has a garbage collector it runs fast. If I'd have to do a casual game I'd choose blitzmax FTW. Tough I'd have to agree with you on some points. The support could be better on actual features not "How would I go to making burning building" or stuff like that. And Lumooja don't say that the support the fastest. Maybe that's because you have a source license but not everyone affords that. Also yes indeed not many games have been made. The free ones can't even really be called prototypes and I wonder if even 5% from the games that people work on will hit the shelves. Still... give it time. Once all the functions will work well it will be really nice to use it. Btw guys if you want to develop a MMO check out Hero Engine. Awsome stuff there. Thinking of buying that just for the pleasure of having it.

You are welcome mate. Hopefully it will be fixed in the final LE2.32 About the camera pick and load/save heightmap I think it was on your email. Anyway I'll prepare a short demo to show you exactly what I'm talking about. Yeah I noticed people who load from the SandBox don't seem to have this problem. That code doesn't work at all on my terrain. I programm in C as well so that's not a problem Thank you.

Hm.. and do you create the terrain youserlf or load it from a file? I create them myself but I have to reverse x and y for it to give the good results on screen. If it's not too much to ask could you offer some snippets of code?(for the camerapick thing) Thanks in advance.

Yes it may be a feature that nobody uses but if you claim on so many ads to have such a great terrain system then it has to be working. Am I not supposed to use a feature that's avaialbe just because other people don't use it? No actual game will be made with the sandbox so developers will have to use the actual engine for this. You haven't answered anything about the camerapick not working on terrains and neither on the loading/saving from file. These are vital parts of a game and they are not working. I'll try your new function and tell you how it's working.

Good to know. Maybe Josh will upload a compiled version here so nobody has to search for it like me.

Thanks Lumooja. For some reason I tought internet archive does not store downloads. But seriously.. A lot of people will need this sooner or later so it could be stored on this website(if the author aprooves it)

From what I understand from the wiki the only way to load a font is to create it with FontStudio. The software exists no more (I tried for like 2 hours to find a download) and thus I can't add Fonts to my interface. Because of the lack of a simple feature as ttf loading (and the "supported" one not working) there is currently no (documented) way of drawing a text with a certain font. Font's are not documented under bitzmax. In c++ LoadFont returns a TFont but in blitzmax it returns a TGLFont.

I sent the textures to you by mail.

Yes I do have those swapped because otherwise it does not work at all. I even had to make my rise/lower terrain functions that way because otherwise it doesn't work at all. Look at this: Method RiseTerrain(px:Float, py:Float, pz:Float, radius:Float, strength:Float) For Local x:Int = px - radius / 2 To px + radius / 2 For Local y:Int = pz - radius / 2 To pz + radius / 2 Local d:Float = (radius / 2 - Dist2(px, pz, x, y)) If d < 0 d = 0 EndIf Local h:Float = d / radius * strength / 1000.0 If h < 0 h = 0 End If SetTerrainHeight(terrain, y + Width / 2, x + Height / 2, TerrainHeight(terrain, y + Width / 2, x + Height / 2) + h) Next Next UpdateTerrainNormals(terrain) End Method Notice this part "y + Width / 2, x + Height / 2, TerrainHeight(terrain, y + Width / 2, x + Height / 2) + h)". I just had to or it doesn't work right. Geez there really has to be a tutorial about all the terrain features.

Nope it does not work: The only thing that get's me a good height is PositionEntity(model, Vec3(p.x, TerrainElevation(terrain, p.z, p.x), p.z)) where p is the pick returned by CameraPick But then x and y are a bit screwed up. Look at tha picture attached. It's as if the x and z are from a flat terrain.

Thanks for the answer. I will try it a bit later on. Perhaps those "strange" values are very small values like 3.234234e-24 (don't remember the exact notation)

EntityPick is useless. I need to pick with the mouse on the screen so I need more than a ray length. Also if I didn't set up Collisions(TERRAIN_COL,TERRAIN_COL,1) it would work at all so yes I did it. Way too much atention is put in that useless sandbox when a lot of very important parts of the engine don't work well or are undocumented. I mean seriously what kind of professional game would use it?

Hey I used this code code to place a entity at the mouse position on the terrain and it doesn't work. Local p:TPick = CameraPick(camera, Vec3(mx, my, 1000), 0, TERRAIN_COL) If(p <> Null) PositionEntity(model, Vec3(p.x, p.y, p.z)) EndIf The x and z coordinates are fine but the y (height) is totally wrong. The model stands in air on some places and then stays in the ground on other places. Anyone experienced this before?

My advice is to use Blide, even if you use the free version. It's a lot better than MaxIDE or even MaxIDE Community version

Did some more sniffing around and I don't think it's my fault Here is a small example: Framework leadwerks.engine SuperStrict RegisterAbstractPath(AppDir) Graphics(1024, 768) Global world:TWorld = CreateWorld() Global buffer:TBuffer = CreateBuffer(1024, 768, BUFFER_DEPTH | BUFFER_COLOR | BUFFER_NORMAL) Global camera:TCamera = CreateCamera() Global terrain:TTerrain = CreateTerrain(512) Global dirLight:TLight = CreateDirectionalLight() RotateEntity(dirLight, Vec3(45, 45, 0)) PositionEntity(camera, Vec3(20, 20, 20)) PointEntity(camera, terrain) SetTerrainTexture(terrain, LoadTexture("abstract::grass.dds"), 0, 0) SetTerrainTexture(terrain, LoadTexture("abstract::mud.dds"), 0, 1) SetTerrainTexture(terrain, LoadTexture("abstract::dirt.dds"), 0, 2)'-Commenting this will make the first texture work with set blend BlendTerrainTexture(terrain, 256, 256, 1, 1)' -\___Both do the exact same thing(actually show only the last texture loaded) BlendTerrainTexture(terrain, 256, 256, 1, 2)' -/ SetTerrainTextureConstraints(terrain, 0, 90, 0, 100, 1)'--Has no effect SetTerrainTextureConstraints(terrain, 0, 90, 0, 100, 2)'--Has no effect While Not KeyHit(KEY_ESCAPE) SetBuffer(buffer) RenderWorld() SetBuffer(BackBuffer()) RenderLights(buffer) Flip() WEnd I wrote on the comments what happens and when. I really don't think it should work that way.

Since I decided to use the terrain leadwerks provides to save myself from some headaches i started to play around with it and got into a weird problem. There is absolutely no info on BlendTerrainTexture on wiki. I basically want to be able to paint my terrain programatically. I see it takes x and y as parameters and I guess those work just the same as the ones from the height commands. The next value is alpha. From what I sniffed around to see I guess it's in range from 0 to 1. Finally there's the layer. I made a terrain with one base layer (0) and 3 other layers. I want to programatically be able to set which one is visible the most. First problem I had is that there is no command to get the blend alpha. I managed to store it separately as a temporary fix. Now I just call this For Local x:Int = px - radius / 2 To px + radius / 2 For Local y:Int = pz - radius / 2 To pz + radius / 2 Local d:Float = (radius / 2 - Dist2(px, pz, x, y)) If d < 0 d = 0 End If Local h:Float = d / radius * strength Local oa:Float = layerAlpha[layer, y + Width / 2, x + Height / 2] / 255.0 Local na:Float = h + oa If na > 1 Then na = 1 If na < 0 Then na = 0 BlendTerrainTexture(terrain, y + Width / 2, x + Height / 2, na, layer) layerAlpha[layer, y + Width / 2, x + Height / 2] = (na) * 255 Next Next Please ignore the fact that x and y are in the reverse order. the same algorithm works very nice for the elevation so the problem is clearly not there. As I press and hold the mouse click on one spot the terrain gets more like a layer's texture. Problem is that it doesn't "go towards" the right layer. It always seems to get like the last texture from the layers. I verified a couple of things in debug: the variable layer has the right value. In the terrain on the layerarray the textures used there are the right ones. Problem must be either in this function or me not calling it right (which I guess it's excusable since there is no documentation). Can anyone help me with this? (I know the code is in BlitzMax but I figure out anyone can understand what's happening there)

Hey guys. I'm trying to make my own terrain system in leadwerks since the one available is not quite what I'm looking for. Since my terrain is quite case dependent I'd like to use basic meshes that are drawn using instancing. I create a patch and after this I copy the entity to every patch in the grid. What I'm not sure about is this: If I somehow modify one patch(verts) will all patches be modified? From what I know about instancing all the verts are in just one array using something like glDrawElementsInstanced. How should I approach the problem if I want to modify those patches?