Hi SolarLune, thanks for passing by; the example which comes with bgui is what I have been working upon since moguri told me about his work(bgui); but strangely it do not show the yofranky image as the previous bgui version (in an untouched form), and running bgui from my game blend(moving the folder to my game “code” folder, a “tweaked form”) produces the aditional following result(taken from a ingame screenshot script, missing yofrank! image replaced by one of mines):
[IMG REMOVED]
It looks to be running in a “barebones” mode(also the bottom input area isn’t accepting any input at all, just the first input area works), I have been looking for path problems in the example and in the bgui files themselves, and I am still working on it. I would like to get the example working perfectly first before creating my own configuration files, but I have been unsuccessful on that for now.
Persistence finally pays off, the main problem was the game camera being configured to letterbox as moguri said, bgui doesn’t work well with it currently. Setting it to extended or scale as he said solved a great issue.
The below input at the sample gui showed void because the font file was missing(hadn’t copied it to my game folder main directory). The rest of the problem was due to python path issues which I will correct properly later(I just used the full path to the defaul.cfg file). Hopefully now I got bgui sample to work allright I can start exploring it.
[IMG REMOVED]
I got too a bloom filter(can’t remember the author now) here at the forum, I’m doing further experiments with python(I’m using just a few needed logic bricks) and got some knowledge about .blend switching/acess from the main .blend; But I want to add more improvements before doing the single monthly release of the game package.
Hi! I have already restored the character creation character view(with very useful help from the BGE forum as always, and my own efforts too of course), by running Questverse.blend you may access this new scene by pressing T or running directly it at startup by modifying a easy to understand code file inside Questverse/system/code. Further controls and possible modifications explanations are in the README/LEIAME files in the game folder.
There is a lot to restore yet from panda3d, and a lot which haven’t even been done. Let me know of any issues with the current package. Do not forget this isn’t a true working game yet, but it sure is an improvement.
I also will let you know by the thread title the current package date.
I already started restoring the game menus, but to do animated buttons the way I want moguri has to implement a feature I requested him some time ago for bgui: The possibility to use a single image representing the same animated item in various states, and cycle by these using only an image positioning variable, like css; so various image files storing each of an item image state would not be need, just one. I will try to implement that myself if I can, as I do rather not loose time.
Also as expected, converting my ink shader from panda3d, from cg to GLSL for a true cartoon effect is being quite difficult and slow; but as I succeeded in learning cg and doing a shader mostly by myself before, this issue is only a question of time.
Other changes were insignificant(or I do not remember now :o), but important as a whole. I’m very happy as I’m coming close to restoring all what had already been done in panda3d(and new features already); from there I will not need to use the word “porting” or “restoring” when describing the game development.
Behold dear friends; I already restored and even improved the panda3d shader I had before(mixing it with shaders I found here). It took a lot of GLSL and math study. That was a great issue before, but now it has passed(most of it).
[IMG REMOVED]
Thanks SolarLune! There are still some issues with my ink shader( which pair with a custom sharpen shader) but i will probably solve them later. Also you can get the shader set at the “cartoon in GE?” thread at BGE support forum or by downloading the next package release(probably out day 15 of september).
Ok, I dropped the votation(as there was no votes for 11 days) and cleaned the files I considered unnecessary from the game package; because of that the size hasn’t increased much in the current release.
I already updated the package 15 days before because I couldn’t stand the old current package highlight image at post #1, which was quite inferior to the look I got now for the test character.
At the package there are now some shader files if you want to study, and also now you can use the mouse click and drag or mouse wheel at the ccreate scene.
There where several other smaller improvements as always. Also in case you wonder why the ccreate screen is split in half, it is because the game gui will appear at the right viewport in the future.
Hope you like it.
Allright, I tried to switch to full dynamic loading for my game, so everything would go only at the Questverse.blend(so goodbye to unnecessary logic bricks and programming in other .blends); did I succeeded? Yes and no.
It was a quite painful process, which even made me give up for approximately 2 days in this feature(after several attempts). I noticed the following(in time order):
1 - Libload set as scene type do not load any of the actions of the target blend.
2 - using libload to do so in the same file after already loading it as scene will return a double loaded blend error
3 - Had to save the same target blend with a different name, and then I could load the actions from my original target blend(because I lib loaded a blend with another name)
4 - Submited bug report about that
5 - Tried blend pepper OSX build, as it was recommended twice for me; the current blender release don’t allow for a controller from one object to activate actions from others, that was why I tried it
6 - custom vertex color shaders didn’t worked, audaspace didn’t worked; but above all, there was an import problem with python time module, which rendered the game unplayable.
5 - uninstallled blender pepper, reverted to the current end user blender; the current workaround? I used a tweaked version of my anim module in the character armature at the target blend as a controller logic brick; I had to set up a complete logic brick environment, with 1 always sensor(with pulse mode on), 1 python module script and 4 action actuators for now.
So in resume, I’m using libload to load the character and his actions(at separated blends sadly), but still using a few logic bricks in the character armature, handling there his animation instead of the main game module in the main blend(Quetsverse.blend) for now. But could already remove the mmenu and error blends; and some code from the character and ruins1 blends.
Because of that I haven’t initiated an attempt to do do myself the image buttons and multiple viewports features on bgui yet, but hopefully will do that soon; probably will be quite painful too, as I will have to learn OpenGL applied in the python side of the program(outside GLSL shaders which was something I learned recently)
EDIT: Well, after all the complaining Moguri showed again the link of the BGE API docs, but they where different now! Now one can load actions too at libload scene type; they changed because of the new blender release I think, I was still using the previous version BGE API pdf
Couldn’t resist to already do some work in the quest1 itself, here is an image of the initial ruins room(not complete yet). there are no shadows because a character with night vision can seen in dark(but I may change the way this power affect the graphics in the future).
It is already possible to walk a bit, but collision is yet to be perfect, as it is easy to fall in the void or sliding without return in a ramp. The mouse look script I coded is going well, but not ready too. I plan to start the “object examination” gui already; but I do not plan to truly complete anything at the quest1 level yet, as I should work in bgui image buttons and viewport support.
If you plan on using some Sort of Celshading for the Environment, then it might work, but as it looks right now… my Eyeees!^^ What ~I~ would do in Case my Character could see in the Dark (with shiny yellow Cat-Eyes, meow :3 ), I would use Rim-Lighting. This Way things still could be drawn dark yet with clear Contrasts at the Borders, Shapes would be clearly recognizable.
(If you like the Idea, take a Look at your Celshading Script – I think it might give a decent Rimlighting/Rimshading Effect with just some modified Values.)
I like the funny way how you say things XD; I was thinking also of; in the case of a full dark environment, the player could see perfectly if he had the night vision power(things would just not get too dark); still thinking about it. I might as well take a look at the environment of some games where the character is supposed to be dark, like vampire the masquerade bloodlines, Soul reaver and Legacy of kain.
It must be well planned, because if the power is present, and all the level would be in the dark; the player would have to endure all a level of the chosen effect.
Well, I think of Riddick. You know, this vindieselesque Guy from Pitch Black. Why does he wear his strange Sunglasses? Because he has got Nightvision – got them from a Priest or something, back in Butcher Bay. And in the Game »The Chronicles of Riddick: Escape from Butcher Bay« (a gorgeous Game, still!) you get this Nightvision after some Time – from then on, you can switch it on and off by Riddick either wearing his Sunglasses or not.
Though if the Effect would indeed be rather subtle, then it really would not bug to have it activated all the Time. However, seeing perfectly? I would find it pretty annoying if I were a Creature that could never ever enjoy the solice Piece of Darkness! D:
(By the Way, your Nightvision-having Creatures–uhm, Characters seem to me rather Cat-inspired, concerning their Eyes. If that is the Case, keep in Mind that Cats do absolutely NOT have an advanced Nightvision – that is just y Myth, actually. However, your makin’ a Fantasy World here, so who cares about the real World? ^‿‿^)
XD yes, already knew that about cat eyes; I saw that in TV(discovery or history channel); they would saw just a weaker darkness(but a bit blurry); also probably with less colors(as full color depend on light); so I’m taking the “is it alien? Then it is possible” approach regarding this. There is also the issue how the light sensitivity would be presented graphically; I thought of screen whitening while looking to moderate light and up(to me strong light would be looking to sun) and the character automatically looking away from it; but my sister said the player would get blind then. Also there should be temporary later screen effects for having directly looked to a moderate light source and above.
I already did my research about the games in my last post and then I “what is that?”, as the games graphically behave as the character was human; there is pure darkness at some places(problem 1), the character behaves normally with light(problem 2), the game leaves places which should be seen illuminated by a lamp, mystical orb light or something(problem 3). Soul reaver was a bit different thought, as it took the “dark, but not much” approach I said before in dark areas by all the game. The player is human after all, but how would I present night vision to him in a pleasant way(and subtle as you said, to not bore the player)
Obs: Vindieselesque was a nice word x]
EDIT: Just letting the audience know I removed the package download links and will only reupload it around septembers end(or sooner); while looking at my current package highlight image I got annoyed by the “void” where the bgui gui should appear(and by the lack of image buttons the way I wanted); so I will take my time to solve both(thought it seems moguri has almost solved the viewport issue)
Beautifull, now Moguri’s bgui support viewport specific guis(thought he still is perfecting the viewport gui input); so the character creation scene got less empthy. It will get complete with some image buttons(with scrollable content) later; but when that time comes not only will it get complete, but all other game menus too.
Also blender revision 39807 already accepts setting a KX_GAMEOBJECT actions using python only; another good news!
All right, now viewport support for bgui is completed thanks to Moguri; but I also did my own stuff too: Now I have coded Image buttons for my game, with automatic image size detection(for almost pixel perfect images), selective texture shown and the possibility to lock a button in a specific state. Already sent that to Moguri so he can perfect it before putting it in future bgui releases, also the automatic image size detection code can be used in some of his other modules.
I was surprised it took only around 3 days(opposed to the 7 days for the GLSL shader), probably because the truly hard stuff(OpenGL) was already coded by Moguri and bgui is well structured. Below are some images(the mouse pointer does not show and they just show button 1 being selected) showing what previously was another game stopper for me.
In case you wonder why the buttons are so small it is because they are from when the game was still in panda3d and worked on a small screen(not panda3d fault, but an option I made at the time), I will rework them soon. Porting is almost done, need only to restore safe navigation(without errors) between scenes
Thats it, I will split the game package itself and the art source files; no one seems to be studying them anyway(if someone is I hadn’t received any feedback); because of that the next package will have half of the size of the previous one. Also I will now work in my game using as resolution 1920x891 instead of 1024x768 which will be the game minimum resolution from now on.
The menus design will have to change too, to be able to look correctly at any resolution above 1024x768.
Finished my new menu layout, projected to look good in any resolution above 1024x768:
[IMAGES REMOVED]
The screenshots got really big with the new resolution, so I cannot show a thread sized preview anymore(many pixels are destroyed as the thread size is much less than that of the game screen). Now the current package highlight images will be shown as thumb sized image and you can click them to see in full size.
Improved the menu layout from the previous post, also changed the size of most of the game icons to be all the same; seeing the images it is unnecessary to say which I will have to remake most of them because of that; I will reuse this layout often because it is very functional, I think it will probably only change on the game quest itself.
[IMAGES REMOVED]
I’m still holding back on showing any videos(which visitors seems to like in a thread like this), because I want a more developed game before doing so; but if you are wondering, the test character shown already have some facial expressions which change automatically with time(besides a body animation).
Well, I have met another BGE annoying issue while trying to do a proper mouse look script; any mouse look script I test from the forum will give a laggy mouse(even with it working for other users); then it came to my knowledge which BGE has issues with mac magic mouse(the render.setMousePosition() function). I coded a mouse look script which minimize this, but hey! I do not want to minimize it, I want it fixed! And this is an issue I cannot fix as it is blender side.
On the other side I finished porting my game from Panda3d yay! Now the game is truly proceeding again(with additional stuff already as I said before). One can already cycle between scene sections, and can navigate some scenes one way only(for now) already.
I’m looking for a good and cheap App for desktop recording(with desktop audio capture, not mic), I know screen flow and camtasia, but look at that! 99 dollars?! I just want a simple desktop recorder(with audio) not a big fully featured desktop recorder. Shame on you Apple quicktime, which only allow to record desktop video without audio for copyright issues; and no, I don’t want to tweak the system with the flower thing to record desktop audio in quicktime.
EDIT: Forgot to talk about other things: first I have dropped the typing interface to do actions in the game; what is the logic behind this decision?
I remembered of the sims 3, you click in an object which can be interacted with and all the possible actions for it will immediately pop up; then I imagined, if one had to type what he wanted to do, even with some kind of aid to show if what he is intending to type really exists, the user would have to ‘guess’ what actions an object can take; what would be the workaround? Use only a set of possible inputs, but then, the game would already had shifted to the ‘buttons showing what can be done’ interface approach(like the sims). So goodbye dictionary.py(from the game code folder) and hello allowed.py(which defines all possible actions in the game) and obj_allows(what actions a specific object can have) .
second: After using seashore for a long time, i must say it, excuse my language, sucks. It has some bad interface planning, it ‘whitens’ images at save time usually and crash often. As soon as the new gimp version comes out, hopefully without X11 usage, I will immediately change to it and switch the credits 2d logo from seashore to gimp.