Microbe Stage Development

Sorry, the last link is still uploading, it'll work in the next 20 mins or so (should be sooner) (edit - it's done). So long as it runs I'm happy!

I've just pushed to my github again, the code there is ussually a little behind my local copy, but it should compile and run something.

I'd like to make an entity system to handle a lot of the interaction between entities, which will effect how collisions etc. are implemented. However, I don't think it'd hurt for you to start working on them now, it'll probably take some fairly straightforward refactoring to get the two working together.

@scio - thanks. If you provide the texture at whatever resolution you create them (within reason), the game will create mipmaps (lower res versions) for LOD, so don't worry about that for now. I'm not sure how texture size affects performance, so I can't comment on that, but I'd guess anything up to 2000x2000 is fine for backgrounds. What would be useful to know is if you have a scale in mind for the texture (e.g.: your clay texture looks a lot better close up than some of the others).

Due to the fact that the player will be an agent of the cell calls you shoulden't implent SDL controls in the init files, because we will delete it anyway when we will create that class... Also, again, please don't use OIS, because if we will need to implent more complex input, we will need to change many things in the code... also, I suggest that you work on the cell class and the compound system because you know the best what to do (As it is your very own system).

I also speaked with the new programmer, and he will post here shortly...
Any who, I don't know how to work around with AOP, so someone who knows how to use it will need to make the cell class.

I will finish the init right now.

I get

Quote :

This application has failed to start because libgcc_s_dw2-1.dll was not found. Re-installing the application may fix this problem.

when I try to run it on Windows XP SP3 in Parallels Desktop 7.

What's the advantage of SDL over OIS? Most of the information I can find on the Ogre forums (e.g.: this thread and elsewhere suggest OIS is perfectly suitable. SDL has a lot of extra features, but not many we need (graphics is handled by ogre, sound by OpenAL etc.), so it seems a little bloated for our purposes. If all we want it for is input handling, OIS seems the better option.

I'll work on the compound system when we're ready for it, we're nowhere near that yet.

@UTeen - Parrallels is an emulator right? We should be able to compile a build for Unix fairly easily, so no need to use an emulator (Mac may be more difficult, as I know very little about compiling on it, and haven't got a machine to try it on). In the next few days I'll get a dev environment setup on Unix and try and get a build out.

I got the same error as The Uteen on a Windows 7 OS. I'm feeling like I am missing something I should have installed.

I looked around and the error they nick and the uteen are getting seems because the gcc libraries are not linked statically. Copying this into the aplication folder will solve it for now (althrough other libraries might be needed). Statically linking them will solve it. I still can't compile it (I can't get along with netbeans, i will try with eclipse later) but seregon should be able to.

This and this links seem to explain the issue and how to solve it.

Thanks Dani, I've made a new build with that fix (download here). I can't test if the fix works, so can let someone let me know?

Don't worry about compiling in an IDE just yet, as that rather complicates things. If you run CMake GUI, set 'where is the source code' to the root of the code, and 'where to build binaries' to a subfolder (in my case 'build/'), then run configure, choose 'MinGW Makefiles', and run configure again until none of the entries are red, then run generate once. Then in cmd.exe go to the build dir, and run 'mingw32-make install'. Let me know any errors you get either in cmake or when compiling, and I'll see what I can do to help.

Wait, it was THAT easy to compile it? I've been like 15 hours fighting with different IDEs trying for them to compile it, and in 6 lines you explain it. It barelly took me 50 seconds for the whole thing, with about 30 seconds being it compiling.

Well, it works great, it compiles without problems, and i'm able to make changes to it. Hurray.

By the way, if you keep the mouse pressed down, the background flashes between the possible backgrounds. What about this instead of the actual code? (Thrive.cpp, around line 224)

Spoiler:

Of course isMousePressed needs to be defined as a boolean outside the function. I would make a pull request to the GitHub, but i don't think i can make a pull request to a pull request (tell me if otherwise)

As far as i'm concerned, the code compiles and runs on something other than your computer, so i vote for merging it to the main branch (better to have some code than no code)

Hehe, that's pretty much what I went through the first time, except it took me nearly a week to get it working at all. This is also why I like CMake so much, it should make it fairly easy to compile on most systems, once you've got all the dependencies. Good to hear someone else got it working though!

I need to run through the setup with netbeans again to get some proper instructions written down, I'll do that later tonight. The way I have it setup now works great, hit f11 to compile, or if the cmakelists.txt has been edited, it runs cmake and then compiles. I may try and get eclipse CDT working again too, but I had a lot of issues with it last time (couldn't compile, no code completion, and finally I managed to corrupt my eclipse install...).

I know the background switching is pretty terrible atm, it was meant as a quick test only, and I didn't want to introduce too many hacks for input handling. Tonight I'll work on getting proper input handling setup, then we shouldn't have that problem anymore.

Agreed on the pull request, it seems fairly stable now, and a good place for us all to work from for now (though it does need refactoring). I don't think you can pull request to my pull request, but you can pull request back into my repo (Seregon/Thrive), which is what the pull request is based on, and that should update it. Once I complete the current pull, I'll close the Basics branch, and we can either work on master, or setup new branches in the main repo for what we're each working on.

The .dll solves the first problem, but it says that it needs another file (libstdc++-6.dll).

Seregon's link gives me a dist.zip with a size of zero bytes. Trying to extract it instead compresses it into an around 400-byte large dist.zip.cpgz. That's roughly a ∞% gain in file size, which isn't particularly helpful. Anyway, the file probably just hasn't been uploaded properly, so it shouldn't be hard to fix. That, or I have a stupid computer, which doesn't seem too unlikely either.

Sorry, I'm hosting all my files in my dropbox, so while I can post a link immediately, the file won't be available until it syncs with the server, which seems to be taking a while. Try it again in 30 mins or so and it should work. I'd provide a download for the other dll your missing, but that wouldn't work for 30 mins either...

edit - the upload has finished, and I've completed merging my code into the main repo, as of right now it's up to date with the latest build. I've also removed the extra branches from my repo and the main repo.

I just downloaded your last upload and it still requires libgcc_s_dw2-1.dll You can try it yourself removing MinGW/bin from your PATH or renaming the dll from there to sonething else (remember to undo the changes later)

If someone else wants to try it, just copy this and this to the folder containing the .exe
The other option is to install MinGW and add the MinGW/bin folder to the PATH

Thanks, it's working now. I'm surprised how good the cells look for a first prototype. Nice work.

What sort of background ‘positioning’ do we plan to have in the final release? Seregon, you said you had switched from a skyplane (basically ‘attached’ to the camera) to a mesh plane background - are you going to leave it as it is now, or is this a step towards a background which can be moved closer and further from the camera, for a 3D effect? As it is now, the (lack of) movement relative to the camera doesn't make it seem like a very 3D environment. Still, it isn't finished yet, so it wouldn't look great, but nevertheless, I'd be interested in hearing your plans.

I've had a few goes now creating a build with statically linked gcc... with no luck. It may be I'm missing something in CMake, but I can't see it yet. For now we can copy the needed dll's I guess.

The cells use a texture from the ogre tutorial kit, which looks a little like a water drop... it's pure fluke that they look even remotely good!

By movement relative to the camera, do you mean having a background which isn't flat, or having the camera move towards and away from it (you can do that already with R and F)? Having a non flat background would look nice, but I wouldn't say that's a priority right now... definitely doable though.

I've got a lot of work on again this week, so won't be posting many more updates before the weekend. I'll still keep up with the discussion here though.

By the way, do we plan on having a main game thread, something like:

Spoiler:

running on a second thread to keep the game moving or just updating everything on each frame, as it is right now?

I would vote for the while loop, to keep things separated, and that will give us more control over what gets updated and when.

If you want, i can prepare the loop and a basic structure for entities, including the player's cell.

It works for me too now, fantastic job! I have all the models/sprites that we currently have. What should I do with them? Send you the download link? Convert them to OGRE compatible files?

Conver them to ogre format, which should be .mesh

For converting, the tools are located here. Then upload the converted files.

I've tried a few more options to try and get gcc statically linked, with no success. For now, I've copied the necessary dll's into the binary folder, as well as providing them in the source, so they can be copied when compiling. This is far from portable, but it will work for now, and shouldn't cause us any major issues later on.

A new build is (or will be, in 30-60 mins) be available here. I'm starting to think I need a better option for hosting these files...

edit - the new build adds nothing new, it simply includes the missing dll's which Dani linked earlier.

I'm not sure about having a main loop or not. Personally, I like updating stuff each frame, as it keeps the code somewhat organised. I'm also not sure if ogre will be happy if we're moving objects around from a seperate thread. If you read the article I linked earlier about entity systems, it seems like a compromise between the two (with many added benifits), where we won't have a seperate while loop, but all control will be handled from a single OnFrame() method. This is something I'd like to work on soon, but I'm not sure when I'll have time to do so.

As far as i know, Ogre doesent mind about moving objects from a separate thread. It is how i did my gravitational proof of concept, and it worked fine. Still, adding and removing objects from a separate thread could matter. But i don't think it will. As long as we do through the ogre methods.

Well, one of the problems i see with updating stuff when rendering is that we won't have a list of everything being updated (at least as it is right now, with the addFrameListener), only Ogre has. At least, if we stick up with the every frame, we should just register a single method to be called and do the updating ourselves, with the list of what needs to be updated on our side.

What i dislike most about merging the game updates with the rendering, on the same thread, is that if one of them suffers (GPU or CPU overload), the other will stop too.Now that i think of it, it makes sense, if we can't render anything, we should stop moving things around, and if we can't move things, there is nothing new to render.

Still, I think objects should be updated from a centralized update function, instead of defining thousands of FrameListeners. Also, some interactions between objects would work better if from outside the objects themselves.

Have a read of this if you haven't already please. As I see it this solves a lot of the issues you mentions. If you've read it already, and you still see problems, sorry, I'll have to give it some more thought. I'm at work now though, so can't put more time into it yet, so will have another look tonight.

Seregon wrote:

By movement relative to the camera, do you mean having a background which isn't flat, or having the camera move towards and away from it (you can do that already with R and F)? Having a non flat background would look nice, but I wouldn't say that's a priority right now... definitely doable though.

Nothing that fancy! 3D backgrounds are something for much later in the game. I suppose I wasn't very clear, though. I mean a 3D… Perspective. As in, when you move the camera, the cells appear to move more quickly relative to the background, giving the impression that the cells are nearby, and the background is further away, giving the effect of a 3D environment. It's mostly an aesthetic thing, but it seems fairly simple and would look nice.

Still, there are more important things to be getting on with for now, and so don't worry about it.

Ah, I get what you mean now. Technically that's already done - the cells are closer to the camera than the background, but I guess the difference isn't big enough to notice. I'll play with moving the background a lot further from the camera in the next build to make the effect more visible

Well, i just finished reading it when i saw your post. Still, it requires us to update each system from somewhere centralized, like the function you have at the end of Thrive.cpp. It was the only concern i had, and it is still there. Sorry for posting so much for such a thing.

If it ends up as good as it claims, it will be great. I had some problems with the first page explanation of how to implement it, especially for how strange actionscript looks to me, so i cannot judge how hard it is to actually do it.

Edit: How does this looks for the background shifted back? Before, the plane and the cells were on the exact same plane, althrough the cells went a bit over it as they are spherical. Now the plane is 10 times further from the camera.
Also, if you keep the mouse pressed, the camera follows one of the cells. I also bumped the number of times the background was being showed from 4 to 9, as in my computer they never filled the full screen.

I've finished adding the netbeans setup instructions to the programming resources thread. If you've not managed to set it up yet, could you have a go at following those and let me know if it works? The setup seems to be slightly different to mine, but I can't quite figure out what I did differently, and this one seems to work fine too.

So your question now is where to put that centralised update code? Either a seperate thread, or what we have now in a frameRenderingQueued() call. For now I'd stick with the latter, probably in a seperate EntityManager (or similair) class, we can always move it to a seperate thread later if needed. (If this wasn't your concern, then I'm being daft and not understanding what you mean, sorry) We can also use this to stagger updates of different components if they don't need updating every frame to ease the cpu load.

I'm still debating whether to try implementing the entity system myself, or use a library. There are a few opensource versions available, and the code is actually very minimal, so should be fairly simple to implement.

Your build looks good to me, I hadn't realised the cells were on the same plane as the background... Odd that the camera following is so jittery, it may need to be smoothed out using a lerp. I'm also thinking that it might be better to have one plane 2x2 (or 3x3) times bigger than the original, with a 2x2/3x3 tiled texture on it, and move that around, rather than dealing with multiple planes. The effect should be identical, and a fair bit simpler. Also - could you push your code back into your repo, I'd be interested to see how you did some of the above.

Even i dont really know what i'm concerned any more, so it's not strange you dont know either. I believe it was to have the code centralized, not where it is executed. We'll need to run it on a separate thread if we want to ever do any kind of simulation on the background, but for the main game it is fine with me as long as it is centralized.

I was alredy starting your guide when i saw this post . I'll post what i find when i'm done here, even if i doublepost.

I actually got Eclipse working, to the point when it handles all the files, has code completion, and gives you information about the things you mouseover. However it can't compile anything. It complains about "Ogre::SceneManager::PrefabType" and "Ogre::SceneNode::TransformSpace" not existing, althrough eclipse can find them. I can PM you the details of how to set it up to the point i am, if you want. I would also like to write a guide about how to get Ogre (and Boost, it is required by your CMakeLists) working, together with MinGW to the point anyone can compile the sources using comand line.

I'll post the code to my repository as soon as i get NetBeans set up.

Yes, a single plane with the texture multiple times would work better, but this is just a first build, afterall. I believe I found the cammera problem. You see, i was moving the camera to the cell current position, and THEN moving the cell. As the camera is centered on the cell, even a few pixels to the side would be very noticiable. Or maybe because i am using setPosition instead of translate. Or maybe it is something else, who knows.

I've been thinking about the entity system, and it would work great for my AI system. The only thing i need is having access to the state of the world, and as the state itself is stored as a whole colectively, we don't even need a function to gather it all. Well, that and that someone asks the agent the action he wants to perform, and reports back the resoult once the action is performed. As long as it CAN be implemented, i'm happy.

There is something else i wanted to add, but i forgot now.
Edit: I remembered just as i clicked the send button. In the setup guide, you mention adding things to the cmake file. One thing i dont think is clear enough is what to do in order to add source files to the subdirectories you just added. I believe that source and subdirectories need to be added in the CMakeList in the directory that contains them, but it could have some rewording.