The real start of the thread is a bit below. Since it was moved to the WIP section (thanks!), I thought I should add some info and a recent screenshot to the first post.

The idea is a to create a village building and managing game, which loosely resembles the old "Settlers II" game. I don't want to implement the combat part, but have a more peaceful settlement simulation.

At the moment it's little more though than a LWJGL based landscape rendering engine, and some basic actions to place buildings and create paths.

This is my third attempt to learn OpenGL. Long ago I had been trying OpenGL and C, but the drivers were so buggy then, that it wasn't fun. Microsoft supllied drivers had different bugs from vendor supplied drivers, and it just was not nice to work with. Maybe that try to too early ...

Year later I tried JOGL, and the reuslt were quite pleasing. I didn't pursue that further though ...

Results of half a day of trial-and-error: A little landscape renderer, using triangles.

Maybe this can become the base for few more modern toy projects, OpenGL is now available on many platforms and the drivers seem to be much better than 10 years ago. At least I can move on from purely 2D development now, and OpenGL seems to be good for 2D graphics, too.

Next to learn: Calculate smoothed vertex normals and enable lighting. Or at fake lighting, I don't know yet what will be the better approach.

Calculating the normals turned out to be quite horrible. Actually not because of the vector math, but the way the map is stored in memory and it's not straight-forward to tell 3D coordinated from the map (2D array) indices. Took a lot of trial and error again, but now I think I have the basics in place:

Now, how can I make the display brighter? I'm not quite sure how to control the light yet.

includes that, but it also comes with a lot of openGL calls that are not needed or aren't specific to just creating textures, and make it very difficult to extract the part that one needs for textuzres and stripü off the rest. Actually I missed one line in stripping (something about Mipmaps) and it caused my textures not to show, while I was searching the mistake in different places till I found another tutorial and while copmparing I noticed the mipmap setting line, removed it, and it worked ... a more focused tutorial would have been easier.

The buggy one I forgot the source. But I Tried the perlin noise code from your blog, and found it (a) doesn't compile, and when I fixed that, (b) smooth_noise() produces 0.0. for each coordinate that I've tried.

Maybe I misunderstood the class. I have ported my old Perlin noise code from C++ to Java, and it worked, so I could continue, but I had expected that the published code was tested before being published (-> would compile at least). Well A comment tells that, but I didn't check all comments when getting the code.

The rest blurred away in my memory from reading too many openGL documentation recently. Ah right, LWJGL API documentation leaves many parameters undocumented which is uncomfortable - even that I can google the functions, in my IDE it doesn't show much, although there was a Java Doc supplied with LWJGL, just it's quite void for many (?) methods.

Edit:

Also took me a while to fi9nd out about this:

FloatBuffer buf = BufferUtils.createFloatBuffer(4);

I used this initially, and it complained about "not direct" which was quite meaningless to me as a pointer what is wrong:

FloatBuffer buf = FloatBuffer.allocate(4);

This is what a Java coder uses if he doesn't know that LWJGL has it's own, special buffers implementaion. Again, I lost time and had to do research why LWJGL wouldn't like my buffer.

GL_DIFFUSE determines how much of the incoming light is scattered (multiples light color).

I guess this means it's safe to use values larger than 1.0. The functions I've understood, I just don't know which value ranges are good/sane/allowed/common. I'm almost completely new to OpenGL, and have no experienc with it.

Edit:

Next step: add billboard trees. I remember there were tricks to circumvent blurry texture borders for partly transparent textures, but it seems I've lost the code from my lat OpenGL test with JOGL, and besides a faint memory that there existed a trick, I have nothing anymore ... I'll see how long it takes to add the trees.

I used this initially, and it complained about "not direct" which was quite meaningless to me as a pointer what is wrong:

FloatBuffer buf = FloatBuffer.allocate(4);

This is what a Java coder uses if he doesn't know that LWJGL has it's own, special buffers implementaion. Again, I lost time and had to do research why LWJGL wouldn't like my buffer.

It doesn't use its own special buffers implementation; there is simply a library-wide requirement that all buffers passed to native methods are direct bytebuffers as opposed to array-backed ones. Blame "Java the platform" for even having the distinction...

1) Switched to orthographic projection like the old settler games used.2) Got panning and zooming in place now (map dragged by mouse - I think it was done this way in Settler II as well)

Display is fast enough for sure, even for large maps with a lot of objects. OpenGL really pays off here

Edit: I found out how to use LWGL to render to a canvas in a AWT Frame. Using other AWT components as part of the canvas worked well.

Can I overwrite the canvas paint method to draw something over the OpenGl output?

I assume I can use Swing components in an AWT panel, but I haven't tested that and it's been too long ago that I used AWT, I just remember that mixing causes problems. But it seems I can build some game UI around the OpenGL display area.

The drawing isn't a big problem, I can either port a UI system that I have from C++ to Java and make it use the openGL primitives, or just write something new. Also it might be sufficient to have the controls below/aside of the world view, that might be good enough. But thanks for the explanation, no I don't need to try it by myself.

When I started to learn openGL for the first time, OpenGL 1.1 was the only standard that was commonly available in drivers. So I didn't look at the extensions and newer version, even at that time.

When coming back, I mad the essumption that OpenGL 1.1 will be available on all devices, and since I knew it will be good enough for my needs, I didn't look beyond that standard. I didn't even look into display lists yet, becuase performance of the immediate mode was good enough and I had enough CPU left on the one used core, so I didn't bother about learning anything more.

But in the book I saw this:

Quote

The only exception to this deals with OpenGL 3.0 and above, relative to previous versions. v3.0 deprecated a number of older functions, and v3.1 removed most of those functions from the API

This actually worries me. I don't know yet which of the old API functions were dropped, but it means that OpenGL 1.1 might not be so universally available as I had thought, and that I need to learn how to do things with OpenGL 3.1 instead. This will take time again. Particulalry it seems to make use of concepts which I considered voodoo (vertex shaders and everything newer - I'm a late adopter and very hesitant with new concepts), and which I wanted to avoid. But it seems that what I considered "voodoo" is now the standard way to do things and I must learn it :/

Well, thanks for the link, it will help to avoid mistakes. The book is easy to read and a good source of information. I don't know if/when I actually will have time and the guts to dive into learning again, but at least I now have a good source of information.

Meh, don't listen to ra4king about all that 3.0+ stuff. The old-style APIs are here to stay for a number of years at the very least. Most Macs are still stuck on 2.1. Even with drivers that support 3.1 and above LWJGL can use the "compatibility context" path which gives you the old-style APIs anyway. So: use the fixed function pipeline.

Meh, don't listen to ra4king about all that 3.0+ stuff. The old-style APIs are here to stay for a number of years at the very least. Most Macs are still stuck on 2.1. Even with drivers that support 3.1 and above LWJGL can use the "compatibility context" path which gives you the old-style APIs anyway. So: use the fixed function pipeline.

Cas

My Mac can't do anything over 2.1, besides, the old stuff can do everything the new stuff can, so uh, here's the deal, why change? [size=7pt]I will keep this opinion until I can get a better Mac somehow.[/size]

I assume that I'll learn more about OpenGL while working on this project. But it's good to know that for the moment I can stick with OpenGl 1.1/1.3. Thanks for the feedback!

Levelling ground was a feature and restriction in the settlers games, because bigger buildings required more level space. So I wrote some testing code to see if levelling is as easy as expected and it seems to be. Just setting the height values for the vertices and recalculating the normals does it.

I've added a few small houses as example, which need a level triangle as ground to be built.

The houses don't blend in perfectly yet. Also I think the ground perspective and the sprite perspective don't match 100% yet, but the code basically works.

Hehe, actually I didn't think much when made the map structure. I just wanted to have two textures to see if the map display works. I also found them useful for tracking the triangle positions and later the tree positions. That's a bit hard without a pattern on the landscape.

Later I'll have some real landscape textures, but I haven't made up up my mind yet how exactly they will have to look. I assume most of the land will be grassy, with some rocky places and water areas in between. I'll need to experiment a bit with layered textures/polygons to make it look interesting.

Meh, don't listen to ra4king about all that 3.0+ stuff. The old-style APIs are here to stay for a number of years at the very least. Most Macs are still stuck on 2.1. Even with drivers that support 3.1 and above LWJGL can use the "compatibility context" path which gives you the old-style APIs anyway. So: use the fixed function pipeline.

Meh, don't listen to ra4king about all that 3.0+ stuff. The old-style APIs are here to stay for a number of years at the very least. Most Macs are still stuck on 2.1. Even with drivers that support 3.1 and above LWJGL can use the "compatibility context" path which gives you the old-style APIs anyway. So: use the fixed function pipeline.

Cas

Why would you limit yourself to the old-style API?

Having the understanding of GLSL will give you a much richer toolset to play with. Personally I did not find myself advancing very quickly with OpenGL until I sat down and forced myself to learn the programmable pipeline. It was only after wrapping my head around shaders did the fixed-function pipeline all come together and make sense to me.

I'm on a Mac with GL 2.1 and I have no trouble playing with fragment and geometry shaders, float textures, texture arrays, etc.

Meh, don't listen to ra4king about all that 3.0+ stuff. The old-style APIs are here to stay for a number of years at the very least. Most Macs are still stuck on 2.1. Even with drivers that support 3.1 and above LWJGL can use the "compatibility context" path which gives you the old-style APIs anyway. So: use the fixed function pipeline.

Cas

Why would you limit yourself to the old-style API?

Having the understanding of GLSL will give you a much richer toolset to play with. Personally I did not find myself advancing very quickly with OpenGL until I sat down and forced myself to learn the programmable pipeline. It was only after wrapping my head around shaders did the fixed-function pipeline all come together and make sense to me.

I'm on a Mac with GL 2.1 and I have no trouble playing with fragment and geometry shaders, float textures, texture arrays, etc.

GL2.1 is still the old-style API. It's only 3.1 (?) and beyond that totally do away with all the old style API commands and you have to ask for a compatibility context instead.I'm targeting 2.1 these days, but still using all my old code; I've just added a couple of shaders.

There isn't much yet, really. A main class, the OpenGL map renderer and some utility classes. If you notice bugs, problems mistakes or anything else strange with my code, please let me know. Since I'm quite new to LWJGL I assume that there are quite some things that could be done better.

Having the understanding of GLSL will give you a much richer toolset to play with. Personally I did not find myself advancing very quickly with OpenGL until I sat down and forced myself to learn the programmable pipeline.

Old usually means well tested, widely available and less bugs. I think I made good progress so far. To get a new display engine up from the ground in about 2 days is quite fast I think. Back when I coded C++, and I started using a new display library like SDL or Allegro, it wasn't much faster, let alone learning an API like GDI for Windows or X11 for Unix.

What I have problems with is the projection matrix, and the sequence of translate and rotate commands. This is due to my bad understanding of vector math, and something I'll have to learn some day.

Since I don't think that hobby project can or should try to compete in graphics quality with professional projects, I rather want to invest my time into the games features. I know for many the big task seem to be to build the "engine", but for me the most difficult task is to build the game upon the engine. I'm quite sure that once I have the besic display in place, the real problems will start for me - the questions how to make things fun to the player, how to keep the player motivated, how to make the game easily accessible to new players. From this point of view a "richer toolset" for the graphics pipleine isn't something that I feel a big need for nor something that will pose a problem for me if I decide that I should need it at some point. It's just that at the moment I think it's not needed for my plans, since I aim for a graphics detail level that was seen in games about 15 years ago. While this was a challenge back then, todays tools make it easy, and I thinks that's what is good for swift progress

I've added code to draw paths on the map (Settlers II style). I have no real maps though, just randomly created ones, so the screenshot shows a random mesh of paths. Still missing is the handling of normals for the paths, but that shouldn't be much of a problem.

I think I have now all graphical elements that Settlers II had - ground textures, paths and objects on the map.

- How hilly should the landscape be?- Which relation of triangles to map object size should I choose?

The latter has the restriction that a map object's (like a house) "width" and "depth" need to fit onto a group of triangles, so there must be some sort of non-fractional relation. But this is a very soft constraint.

I've been trying to improve the landscape generation a little (valley bottoms are more flat now, and hills more pointy), and added some in-between textures. Not looking too great, but it works.

Next will be to get the calculation mouse position -> vertex so that the user can interact with the map. And I must decide how to build in-game menues (AWT popups, pure OpenGL code, UI besides/below the map display).

The shading is a feature of OpenGL itself, if you supply normals for the triangle corners. I'm somewhat confident that I can make the texture transitions look alright in the final version, but I haven't worked on that yet. The textures themselves need more work, too.

A big step forward is that I can handle mouse input now. I mean to transform the mouse x/y coordinate to a vertex or triangle of the map. So I can start to build a UI now to control the game.

Since it's an AWT frame it seems I can use all AWT components, but a quick test with JPanels and JLabels seemed to tell that I can use Swing components too. Next steps will be to give the player tool menues to place buildings and create paths.

But... somehow... I wanted to give the medal to the post before the one I medal'ed... strange thing... I SWEAR I have't even seen that post :O

EDIT: On-topic:You should try doing the shading in the Fragment shader.Really, there is almost no hardware out there, which doesn't support OpenGL 2.1.

And in the end GLSL isn't too hard either. You only have to write yourself some utility classes like a Class for compiling shader-programs (or better: call opengl, to compile the GLSL shader), or just find on on the internet. I really have to say, that lwjgl-basics is a pretty good project by davedes. I've contibuted to it myself, and it really helped me a lot since then.

I can draw from some older projects of mine, also there is a lot of helpful stuff on the web. And I assume I just put a lot of time into it. Almost worked last night through because I wanted to put together a first demo.

That's my bane. My interest in my projects comes and goes in kind of short runs ... usually they sleep a while, then I get some new ideas and I work on them for a few weeks, then they sleep again while I work on another project. I'm trying not to let my project list grow too much so that each sees some updates a year. It's kind of project ADHS.

The gardening simulation is on hold currently because planting and watching plants grow felt a bit boring, and I haven't made up my mind yet how to make it better. A faint idea is to allow some multi-player features, like sharing selfmade plants, but I'm not quite decided on the path to go. So it waits till I have new ideas again.

For today, I have put together a little demo. It's mostly to see if the code runs on other systems but mine, too, and also to get a little bit of feedback, although there surely isn't much to comment on but if zooming and panning works, and the like.

So far I've only taken care about windows and supplied a "star.bat" which starts the Java runtime with the right parameters. Some day I hope to have a better startup system which works on Linux and MacOS, too. I assume you could copy the start.bat, and transform it into a start.sh which does about the same thing for Linux, but right now I have no Linux system to test that.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org