About this blog
The journal of nano size but tera quality. Sometimes.
Entries in this blog
I have just finished doing a bit more to my GUI Editor. I have currently got it so the edit box widget will only display enough characters within the widget to fill the display area- a bit like windows edit boxes when you have a string longer than the edit box can display so it cuts off the end. Anyway, difficult to describe but very useful.
Once I finished that, i started on the tool bar for my GUI Editor- naturally I started editing it within the editor itself to make life easier.
The toolbar consisted of 7 labels and 7 edit boxes and the normal sys.Stak window style. However after about 3 minutes of using the editor with those widgets loaded it crashes and tells me i'm out of memory. I wanted to investigate further; I opened up Task Manager when it was running and was shocked by a peak memory usage of around about 350MB. Jesus Christ Almighty in a satin nighty!
Anyway, this has urged me to get down to some heavy optimizations!
nothing much else happening. Just a load of work and programming and I got some guy stalking me but thats about it.
I've decided to leave my GUI Editor for a bit because I don't have the energy for doing heavy optimizations. So I have gone onto two other projects- Raytracing is just a side thing I want to mess around with and AngelPMX Compiler is the main project I'm working on that will compile my scripting languages source files into executable binary files for my engines runtime environment. I'm starting with a basic syntax since I have not actually written a compilable scripting language yet so I have got a kinda ASM syntax. Hopefully I will expand this as my knowledge increases.
Its quite interesting writing a compiler apart from the buzz of feeling uber-1337 with your codin' skillz [smile]. It gives you such an insight into what your actual compiler is doing. It gave me the same illumination as when I started mucking around with O/S development and I had to manually link everything with GCC and do a whole load of stuff that MSVC++ does automatically.
The thing is, I take compilers for granted and don't really dig far below the surface but when you start looking through the features of MSVC++ you really how freakin indepth it gets.
Anyway, after I have finished the compiler I'm gonna start on the runtime environment proper. I have the basic setup thats similar to all the other sys.Stak tools however I am going to add the virtual machine to it. VMs are something I'm really looking forward to reading into. Again, this will be a simple VM for my scripting language but hopefully it will expand.
As for raytracing- You know you have some hardcore calculations getting pushed through your CPU when it takes over 2 seconds to render a simple scene- 0.5FPS!! You know your scene rocks some[smile]. And i'm only doing, like, the first tutorial[smile].
Anyway, nothing else happening- work, games and photography.
Keep it real,
I've decided to actually keep a journal now.
Went clubbing yesterday till 7am this morning. It was Slimelight in london.
I decided not to get pilled up this time which was probably a mistake since I was knackered before hand (pro plus were doing nothing) and I fell asleep after about 4 hours with only a few dances under my belt.
Quite a few fit guys there. Not so many fit girls (not that I was looking...cos I have a gf).
Saw a strange woman who was dancing very very slowly to fucking fast up beat trance music. She seemed to be majorly spaced out on something.
I've got the next few weekends booked up which is good. I got a BBQ next weekend which I am going to buy a few shrooms for so we can all trip out with our burgers. Then saturday week we have the monthly brighton clubbing trip with my workmates- The Safeway/Morrisons Krew! I dunno whether I'm gonna get pilled up for that; the last trip was really amazing without any drugs (apart from joints).
I've made the decision to actually go extreme cybergoth very soon. I've been quite traditional for years now but I really want to go extreme. I got the perfect hair style in my mind and I'm gonna get a few more tattoos and piercings.
I've left my game engine for a few days now. I've gotten quite far with the GUI editor tool- so useful since I can just throw together windows for my engine. But I have run into some very illogical problems.
Also been reading up on CPU and hardware emulation. Very interesting stuff and something I want to read into more depth and do a bit of pratical programming with it.
Yesterday I decided to get some more rave pants from Cyberdog. I happily spend 60 quid on these. They are sweet as-
Over and out, mofos
That title got your attention [smile]
I'm feeling alot better since my last entry. The flu-esque virus I had has subsided somewhat. If i don't take any medicine I do feel like hammered shit though.
I've been doing a bit more to my GUI Editor. Just got a few more things sorted out in my head as far as the mechanics of the tool are concerned and also been thinking ahead a bit :0!
I have been thinking how my GUI will interface with my engine in the most efficient and easy way. What I have decided (i'm not sure if this is the norm for engines) to have events (bit like windows) and with those events, eg OnClick for buttons, I have a script file and function within a script file linked to that button. When the button is clicked, the GUI pushes the function onto the engines 'script stack' which means that events script will be processes first (kinda reverse to a message queue). How I figure it, GUI events take priority over other aspects of the engine. I'm sure this view will change the further I develop sys.Stak, but thats my view at the moment.
This way I can have the whole GUI events driver completely modular to the engine so I can edit it outside of the engine.
My overall aim, as you may have noticed, is to make my engine as modular as possible and have the main driving unit of the engine as bare-bones as is can be.
This way, I have far more control to develop outside of the engine.
As far as programming is concerned, i've started on my Edit Box widget. I have always dreaded this and, I now know, with reason. Label, window, icon and button widgets are so easy since they don't require their own input method or removal of text to only display a section within the widgets area. I know how I'm gonna do it, its just gonna be really laborious to implement. The GDNet lounge has not helped me the past few days since I find myself frequenting there when I have intentions to do more to my GUI Editor. Madness.
In other news, i now have a really nice new small T-Shirt from Cyberdog.
My camera has run out of batteries so heres a description:
As with everything from Cyberdog, it is a cool club scene t-shirt with circuit pattern all over it on black material.The circuit pattern is dull gray until you shine direct light on it, at which point it shines up. Its really nice!
I also have quite a decision infront of me-
spend some of this months wage on a Geforce 6600LE from XFX (~200) or a new camera (~280).
Cannot for the life of me make up my mind...!
over and out
Steam drive is making slow but steady progress. At the moment I am making a small multi-format model viewer as a tool for the main engine. This tool is allowing me to write all the basic engine routines like the console, model loading etc. in a small easy program. This will make it easier to write aspects of the engine without getting bogged down in the rest of the code.
Its just my way of learning...start small.
The model viewer is coming along well. I'm currently writing the logic for the console.
Long time no update again.
Well, thanks to all those who have helped me with collision detection. I have used that information in conjunction with some good tutorials and realised that my current LD map format is crap and is too mangled to actually perform collision detection happily and successfully.
Taking that into account I am about to venture on a journey but this journey has already been done before. I'm rewriting HUGE amounts of my level format (thats quite a few months of work) and try and make it neat as possible. My idea is to integrate the level class around a tutorial I have read. I understand the theory behind collision detection but my level format is stored in such an obfuscated way that its almost impossible to do vaguely complex maths on it.
I may even go so far as to scrap the current format and start anew.
I can almost feel the fresh air sweeping over the age old cobwebs of my code [smile].
Well, here I go- starting some calm DJ Shadow and starting up Visual Studio...Wish me luck.
Welcome to my reformatted journal!
Reformatted? It looks like my other entries. That may be true from a cosmetic point of view, however I have changed the way I view my journal- thats the reformat.
From now on I'm not going to update the journal every now and then based on Nanostem developments but also from what I have personally learnt about the whole development process from experience with Nanostem but also from other sources.
Yes, you may well be saying there are lots of journals on here that do just that and there are loads of developer blogs but from my point of view this is for me to look back on. Partly to see progress and also to review and re-establish knowledge.
The one achievement I have taken great pleasure in retelling is the fact I changed my girlfriends view of games and their development as something that is void of creativity and results in something of a pointless nature. From that point of view (which, might I add, was almost unmoving) to a view that yes, games are an artform in themselves, in their own right. That was a proud turning point and hopefuly I will bring that, along with my fellow GDNet'ers, to a far wider demographic. I have no doubt that many if not all of us are wanting to see games respected; not from the units sold to the unwashed masses but as something as critically viewed as movies, novels and paintings.
Along the same vein, I regularly discuss the latest things I have learnt and appreciate in games design and implementation with my mother on dog walks (what better place?).
Recently I played HL2:E1. Then I replayed the entire thing with commentry nodes on. I really like this idea since in a small way its provocing peoples ideas of games as an artform. I learnt ALOT from the commentary nodes in Episode 1 (if you haven't replayed it with commentry nodes- Do. It.).
One commentary node stays in my mind- when you come out of the subway thingy (with the missing handle to open the door) and you emmerge to a scene of apocalypse with the citadel dead centre. The node explains how nothing in that one player view wasn't postioned willy nilly. It was 'painted' to make sure the players eye gazed over the destruction, a strider jerkily negotiating the rubble it created at its feet. with the once forbiding icon of fear and endless power, the citadel, now a decaying shadow of its former self dead centre with Dr kleiners voice echoing out with messages of hope. It was instrumented so the player would see all this and appreciate what it was trying to say. That is a work of art.
The thing I learnt from just that one scene is two-fold:
I knew design was intense, for want of a better word, but that really brought me to a new level of what it involves. Ok, it didn't cover every avenue of design but it opened a door for me and understand a little more which can be brought onto other aspects. Many of you may be looking at that and thinking 'well yea, thats stating the obvious. Of course thats the level that design involves'. Well lets not forget- I'm using this to look back on and lets me place the ideas and theories I have learnt for later review.
The other thing I learnt is if people understood how much goes into one little thing like this they will begin to appreciate games beyond the button mashing. Thats why I like the commentary nodes that Valve do.
The thing I brought up with my mother on the dog walk was the fact, ok this may be a leap, that epic game sagas are a culmination of so many, if not all, forms of art. She did agree, by the way.
As far as Nanostem platform is going- well I have full collision detection, a basic form of troop movement and the foundations of a relatively sophisticated C-like scripting languages (parser within the engine- I know, not the most speedy way of reading scripts). My next plan is to get a decent level of control over the CellScript language and get the rest of the team to start with content building- thats long over due [smile]
Anyway, just 2 weeks worth of thoughts and about 2 months of development spat out into one Journal.
Hopefully see you soon back here
Hi de hi all!
just a quick update on my editor.
I now have control over how the textures are presented on primitives. It took me about 3 hours to change the map format to enable me to change the coords on textures and to implement a feature to flip textures, change their coords ect.
So yet another feature is added.
I would like to add that my girlfriend (codename: Lazyfox) quickly sorted out some of the texture coords that were going wrong. So thanks LAZYFOX!!!!
I would like to point out that no she can't program, it was just easier to quickly draw a diagram and have her work out the coords while i worked on another aspect of the editor. But I would like to teach her how to program one day [smile]. I got her onto computer games and by god that was a task and a half[wink]
I would also add that she won a game on unreal tournament (for the first time)... in the words of 'Purepwnage.com'- she has uber-micro.
(Albeit on novice [wink])
over and out!
Having just got comfortable with some of the aspects of my editor I realise the current map format is just not powerful enough. Instead of control over whole primitives I need control over verticies. So I am right now changing the whole map format- instead of cubes/spheres etc I have decided to make the most basic element a polygon and then I can have a kinda embedding system where I can declare a cube and then declare the different polygon elements. Within the polygon elements I declare the verticies and their co-ordinates. I should really have thought this through before starting on the format- polygons should be the most basic elements...
This will hopefully give me a far greater amount of power and control over the architecture of levels within the engine.
Having said that, its still as basic as shit. I'm not expecting the next UnrealEd but at least something to create content for my engine.
It seems to me the most amount of time in single handedly writing an engine goes into writing the tools for content development rather than the core engine itself. I guess the next largest amount of time is taken up with content delivery. But it has certainly been quite an eye opener developing an engine.
In other news:
I got my girlfriends prom/ball thingy tonight. I had mine last year and thought it sucked (it was her who got me to go to mine) but this time its her finishing school so I gotta go and escort here there. Getting nicely gothed up and being a bit victorian. Sadly I gotta go in a limo- I cannot stand limos!
Nothing else at all interesting.
Just said goodbye to my gf. shes going for 2 weeks to the british virgin isles. I'm gonna be a wreck without her :(
The plus side is, I will actually be able to really work on my engine for the next 2 weeks [smile]
oh, and I treated myself to a new mobile phone to keep my spirits high: T-Mobile MDA Compact
I've seen it in action and its a beautiful beast[smile]. Apparently it will arrive tomorrow...cannot wait!
Engine Update: I've done pretty much nothing apart from start writing a wrapper for MD3 models.
been a while since I last posted on here.
Since I have, I decided to scrap Quake 3 BSPs in favour of my own map format.
I feel this was a good decision since I now have far more control on the way the map looks and works. It also means I can add and remove different things from the file.
Once I had the basic map format sorted out and a renderer written for it I decided to write an editor. Keep in mind the map format is VERY basic at the moment and only supports cubes but does support multi-texturing and stuff. However it does have the ability to expand to allowing just about everything. Also the editor is very simple as well- it kinda reminds me of the good old days of doom map editing. At the moment it works on one viewport by 3 views- top/front/side. You just scroll round them. You have full control over the cubes but at the moment they are controlled by the keyboard and as of yet has no ability to assign textures. You add primitives through console commands. Having said that, not bad for one days work [smile].
heres the editor in 'Edit' mode:
And heres a shot of the editor in 'World Preview' mode (With engines default texture):
Anyway, I am going to continue with this full on in my spare time. I am much happier now I have my own custom map format.
NanoStem Migration Update
As I said previously, I initiated a group decision to migrate all the old OpenGL code to DirectX.
Well, for the past 3 days I have been very busy rewriting pretty much everything and I'm still not there.
Basically, I had the implementation in my head but inorder to do it with DirectX I had to rewrite the main base of the engine. Once I had my fundementals in place (DirectX Graphics Manager, Vertex Buffer Manager, Texture Manager etc) I could start rewriting the next level of the engine.
Now, with all my projects I always like to have some form of interaction with the inside of the engine as the first step (I find its easier that way). So I always implement a console system- its invaluable in the early build/debug stages of the engine.
However, my old console class was a bit clumsy and bloated so I decided to write afresh, infact I decided to go a little deeper and make the console class out of objects of the UI I am going to work on soon. So I wrote some fundemental bare-bone UI classes, like CUIPanel and CUIImage, and used them to construct the console. Whereas before, I had constructed the console out of its own bits and bobs- this way I feel it is more integrated.
I have also looked at all the old classes and made them far more OO and writing them so they can easily be plugged into other classes without much hassle.
I have also started writing up official reference documentation, which makes me happy. Along with that, I spent 45 minutes doing a new logo- I'm really pleased with it since it is more clean and professional looking.
Anyway, heres the first blinking cursor of the Console:
I have actually really enjoyed the migration so far. It went off to a bumpy start but I have got a vision to follow now [smile]
I got to the point with my editor that I can actually make basic levels. You have no idea what kinda buzz i'm feeling right now [smile]
Anyway, yea, so they are basic levels and the editor doesn't have the ability to add textures to the different faces of primitives quite yet- basically I'm only showing you the top view of the editor mode. If I showed you the world mode, all you would see is the default orange texture my engine uses for untextured faces.
Anyway, here is my E1L0 level (random name, nothing to do with iD softwares stuff [wink]) [smile]- it is floored and walled but no ceiling since my engine has no need for ceilings:
Well, I'm quite pleased with my editor so far [smile]. The mechanics have not been improved yet but I have got a world camera working now so I can actually look around the levels I create from within the editor.
I had quite a bit of trouble with the camera system until I asked a question in the forums and the answer was embarrassingly easy and something I had already tried but didn't seem to work previously. Anyway, thanks JavaCoolDude for you help [smile].
So now I can show you the top down view of E1L1:
and a look in the level (with the default texture):
I am quite pleased with the progress so far.
Next thing to do, all for texture on each surface of the primitive. As I said before- I already have the flexability for that in the map format and the renderer but its just a matter of implementing a method to change it within the editor.
I also need to look into full control over texture mapping. Time to dig my teeth into the infamous 'Red Book'(!).
I'll keep y'all posted!
Well, I have been up since 0530hrs (I was doing the Deli open up at work) and I got slimelight again tonight.
Slimelight is an alternative club up in london full of Cybers like me (Yea, i'm a freak of fashion and have a shed load of cyberdog clothes [smile]). This club is open from 2230 till 0730 which means you need a hell of alot of caffeine or in my case a few other things [wink]. So its a long day for me.
Anyway, i'm gonna request loads of hardcore from DJ Promo and Neophyte and stuff. Do any of you have any other suggestions?
Well, if I'm still alive tomorrow I'll update on how it went [smile]
Catch you later people!
After about 1 month of development and having sorted out quite a few of the native formats for the engine we had a team discussion, initiated by yours truely, and we have come to an agreement that I will migrate all the current code over to DirectX. We came to this dicision for a number of reasons, including the intuitive structure of modern day DirectX. Thankfully it is only a months work and most of that has been a load of fiddling rather than anything too new.
So anyway, you probably won't see a huge amount of updates for the next week or so as I migrate the current progress over to the DirectX platform.
I'll tell you how easily or how sketchy the migration was when its done.
It may sound like an unprofessional decision to change platforms but this is our first project so the beginnings are bound to be a bit wooo bit waaaay [wink]
Anyway, I hope I will be more comfortable working with DirectX- will have to get my head round it again :)
take it easy
Ok, i have got the most basic element you can work with being a face, like a standard polygon. This made my simple editor a bitch to use and quite frankly impossible to make anything.
I loaded up UnrealEd to see if that could inspire me as to how to make editing a bit simpler.
It seems that UnrealEd allows you to add a simple polygon but also a cube and things which means I was onto the right idea before. The only thing that is different as far as cubes are concerned with my old build of ZnO/S Ed and UnrealEd is that you are able to control the vertices. Since I have already got a system in place for loading up individual verticies I have no probs with that; just means changing the map format. Also I have in place a system for just putting in bog standard 1D polygons so I have 2 primitives already in place.
I also plan to bring all the views into one viewport so I have:
| t | f |
| s | 3d|
but I am not totally sure If I will have a 3D view.
However, I will slowly bring this feature in when I have time- at the moment, the mechanics of the editor are far more important.
Also, I have to have a proper look at the map format. At the moment I don't think I still have enough power and flexability. This is the most important aspect of the whole editor.
What I'm going for is quite an iso-pers 3D platform style world. Thats it in a nutshell, however its slightly more complex than that and the game I intend to have at the end is not cute or cuddley but for adults. As far as mechanics are concerned, the levels are going to be, as stated, iso-pers platform but with full Y axis camera control (Otherwise I would do an Isometric engine. Although I did try that at one stage and found it impossible to do collision detections. Got very confused[smile]).
I have what I want in mind but its just a case of translating that to a map format and a map format I can actually write an editor for.
So thats two concerns I have to deal with in the context of the map format.
Sorry, this is a bit of a random update but I am trying to keep a history on how I did this editor for my own future reference. Also a current reference.
Honestly, I'm going to have to start writing down plans for my applications since I'm getting myself into a total muddle here.
Over and Out
I spent all day trying to work out what API I will use to play sound and music. In the end I landed on FMOD, and it seemed like Stompy had a lot of success with it so I thought... hey what the hell.
I love FMOD! I got the latest release- FMOD-EX 4.03. It is fantastic with a fully object oriented approach to development.
Anyway, just spend about 40 minutes writing a basic wrapper class and its working very well.
I just played my first sound bite- The reconstructed voicemail from 12 monkeys. I felt it was kinda appropiate for the engine [smile]
Anyway, HaVe a MeeeeeRRRREEEEEEEEE CHRISTMMMMMAAAAAAZZZZZ
(12 monkeys reference if you haven't seen it[wink])
Just a quick update. I was a bit disillusioned in my last post about the lights mainly because they were just not working correctly. I just fixed it and it was too simple. I just had to note this down incase it helps with other people and also to act as a reminder for me to actually read the code I have written.
The thing is, my maps are scaled down defined by a scalar value in the map format (I know, its not a good idea to use scaling but I find it easier). Anyway, having read NBs about normals having to be one unit long otherwise lighting screws up I remembered to add glEnable(GL_NORMALIZE) (The one that requires more computing). This makes sure that the normals are 1 Unit, no matter what. So I did that but the lighting was still mucked up and looked like a normal bulb light over a model village (So the normals were still the same size- See screen shot in previous post- that was diffused on .2 ...no chance that it should illuminate to that level). Anyway, I was looking through the code and couldn't find anything that was wrong.
I left it a day or so. Then I read through the information in 'The Red Book' and scoped out something that might be the root of my problems- the lighting is calculated using the model view matrix. Whats that at the top of rendering each singular entity of geometry? glPushMatrix(). The thing is I was pushing/popping a new model matrix everytime I rendered a primitive but my ModelLighting(int LightType); function was well before I Pushed the matrix which means the lighting was being based on a non-scaled model view matrix and that meant no matter what the lighting would be screwed.
Hazzah! another problem solved.
Lesson of the day- Always read your code and keep track of the times you push/pop matricies.
[Disclaimer- Do not comment on my bad over complex programming style [smile]]
Now I have a whole load of cycles wasted on iterating through the list of lighting in my level every time I render a single primitive. Major optimizing is required! I say again- Major optimizing is required!
Anyway, thats how not to program [smile]
Catch you later, dudes
I have two things happening at the same time at the moment, and they are both quite procedural:
For our course we have to learn the basics of MatLab but typical of me I'm throwing myself well into it. Its actually a very intuitive language for hardcore maths... thingys.
By the end of this semester each group, we've been split into 3 groups, has to make a section of a genetic algorithm. We are the section that gets all the results from the initial population test and then we have to statistically select a number of the population to be passed on for the the inheritence sorting group. Its all quite interesting- basically taking a matrix, doing random selections of rows of that matrix and passing on another matrix of the same size.
I'm now looking at procedural generation as one aspect of the engine. Since the engine will have huge open sections, procedural generation will be perfect to:
Build huge vistas in one single generation and save it to the format. This avoids man hours in sculting out the land mass
Keep resource files to a minimum since some of the ingame content will be generated on the fly
Look pro and have the current buzzwords "Procedural Generation" printed all over the engine [wink]
And thats pretty much where I am at the moment. However, when it comes down to it, I might just make a vista editor (No affiliation with Microsoft) so we have full control over the look. Either way, its quite interesting reading.
Its A Bit Shady
Just posting to say I have been working very hard on not only college work but also our engine. The landscape editor is becoming a most useful test bed for the engine. I'm using it to systematically implement and test features of the engine that are on my checklist. 4 days ago I managed to get simple lighting to work which gave me the natural direction of implementing shading.
So here I am, implementing the shading engine and having great fun with it too!
I'm currently only using the original specifications of GLSLang but will implement GLSLang 2.0 with a fallback to the original.
So far its going ok, except for some of the vertex lighting so I gotta sort that out. I think it may be something to do with the normals...
Anyway, the engine is generally flying on at high speed (well, high speed for me [wink]).
I'll post up a picture of the editor once I get per pixel lighting to look good.
The Story So Far...
God, its been a long...long time since I put anything into my journal.
I've been quite busy just getting stuff for college sorted out in the past few months and havn't really had the time and/or motivation to work with my game engine.
However, i've had my first few weeks at college for the foundation year before uni-proper and I'm really enjoying it (granted, i'm wishing I had actually turned up to my last year of A-Levels a bit more since I would be AT uni by now if I had). That aside I have a good bunch of mates at college now and will try and keep them as mates since we are all going into Halls of Residence next year at Sussex Uni.
Now I'm finally settled I'm getting back into programming and into my game engine.
I think the reason for me not working on the engine is because I have come to the ever fun obstacle of collision detection. I'm diving and taking no prisoners; I will get my characters bouncing off the walls (...in a good way).
After that I plan on getting the lighting a bit better and starting on a basic scripting language. again. Also I have in my mind to refine the map format a bit and add more flexability.
In Other News
An e-mail caught my eye today and guess what...? I love the new look to gamespot; everything is just a few clicks away. They have made it look far more professional and the integrated player looks sweet. A bit better than Windows Media Player style buttons. Fresh Tuesday is quite informative for a quick overview of the latest happenings of out mad-cap industry.
On the downside are Gregg Kasavin's awful sarcasm/quips/jokes on the redesign overview video. Have rotten tomatoes at the ready[wink]
I also got 'My First Car'- its a Ford KA that came with an OldSkool tape deck for a sound system. Blink and you'd miss how quickly i replaced that a Kenwood CD/MP3 player and Fusion Sub and Amp. I can pretty much roll my car from the vibrations.
peace out y'all
Hey, hope everyones good
I havn't updated in a bit since I have had quite a bit on but I have been scoping out other peoples journals and been keeping an eye on the journals I have become a regular to [smile]
Anyway, I have decided not to go into advanced lighting quite yet. I got basic lighting up and working (not that amazingly) but it still gives the illusion of depth to the level.
I am going to get back to lighting at a later date, its good enough for me at the moment [smile]. I am actually working out what aspect of The Engine I want to go onto next.
I am eager to start making content for game the engine is being built for. My gf and I have already started planning the content which is always a good start. So my next effort will probably be content, so that includes all the basics of character movement and things. Just get a basic interactive system working (Then get back to the lights [smile])
Oh, heres a quick shot of the test level in the world view of the editor:
Over and out
Just done a bit more to my GUI Editor for my engine.
Heres a screenie if you're interested. Ignore the broken graphics; I havn't got around to fixing that since I have been concentrating on the mechanics of the editor.
Currently you can:
-Load up previously created windows from SWD (Stak Window Descriptor) resource files for editing
-Save your current window to an SWD resource file
-drag labels around using the cursor by selecting their 'pin' (little green things)
-Drag buttons around by just dragging the button widget
-Move/Transform the window using the cursor
-Change all the captions using the console (havn't yet got a GUI for the GUI Editor per se, just the standard sys.Stak console)
-Use most of the other console commands that are used with the GUI
-Add new labels (through console)
-Add new buttons (through console)
-Remove labels (through console)
-Remove buttons (through console)
-I will add a GUI (other than the console) once I have a complete GUI system setup
-I will add the feature of linking script events to buttons clicks once I have a stable scripting language sorted out
-Make more widgets! (Edit boxes, memos, lists etc.)
Just incase you were wondering how the windows look without broken graphics (This is from in the engine not the editor):
Not quite as bad :)
Over and out, mofos
Dunno how people but I forgot that GDN+ has a journal/blog feature (even though I have already added one entry).
Anyway, sys.Stak engine is coming along nicely- just started on the GUI after hacking around the problem with falling through or 'ghosting' through the floors of Q3BSP maps (I did it without a FPS limiter). So now I can concentrate on the interface which is what i'm doing now.
I have decided to take the bog standard approach to the interface with a main interface object and all widgets derive from this object. I have the CStakInterface as the base class for all derived objects, then I have CUIWindow, CUIButton etc.
So I have it all sorted programmatically but what happens when I come to properly implementing an interface with multiple drag/drop windows etc? Only time and hacking around will show results.
Yea, I enjoy hacking around my code. Its cos i'm lazy ;)
Have a good one,