12.05.05
Posted in ALPHA, Programming, SGE Enhancement at 1:47 am by Nick
Time: 2 hours
Total Time: 80 hours
——————————
Twas poking around Game Dev.net yesterday when I found an example of how to use fonts in your game. I modified the example to work with SGE (aka ripped out the DirectDraw stuff) and gave it a go. It seemed to work alright, though it flickered.
A few minutes later I realized I was drawing to the screen instead of the buffer (defeating the purpose of double buffer imaging). I fixed it for that and everything was quite snazzy.
After playing with it a bit I decided to expand it a bit more, and allow the user to specify weight*, strike through, underlined, and italic’s. This made the text a bit more useful.
I also figured I should make a few global fonts (mainly being Arial, Comic Sans MS, and Times New Roman in sizes 16 and 20) so I didn’t have to “create” them every time I wanted to use them. While it wasn’t really visible since the calculations for such a thing take nanoseconds, making an init_fonts() function just seemed like a good idea. I also made a default font that is used primarily, and you can change what it happens to be within the init_fonts() function.
All of this is leading to a messaging system, which is why I call this a font engine. Eventually it will support background images for text boxes so it will be a bit more like normal 2D games. While I’m not sure how I want this to be scripted, I do know I will eventually write the code to put this into the scripting system.
Overall the scripting system is a difficult subject, as it is only good at one thing currently. It is used for level creation. This is very nice, but it has nothing to do with events that happen during run time. I think I may want another scripter that can handle a level’s events. What this means is making a new system to parse new types of scripts. The scripts would specify what to do during certain events. A few examples are below:
- Print the opening dialogue using the font engine
- Play a cinema after an event (hmm, cinema support… ::adds to todo list::)
- What to do when the player dies
- Specify various behavior patterns of enemies (beyond the scope of the current AI scripting)
- Make, create, use, handle, and keep track of variables used for a certain stage (suppose a player is collecting items for a certain stage, etc)
–
*For those who don’t know, font weight is how thick it is. For example, normal weight (like the stuff you are reading) is weight 400. Normal bold is 800. Weight goes from 0-1000.
Permalink
09.23.05
Posted in ALPHA, SGE Enhancement at 6:48 pm by Nick
Time: 10 hours
Total: 35.5 hours
—————————
Despite the numerous posts under the GID 15 topic, I never had an official overview for my log. So, here it goes.
These were the main things I recorded as getting done:
————————————————-
*Add scripting ability for AI functions
*AI function pointer to sprites
*Add ability to script a STARRY background
*Add ability to specify transparent color on bmp’s
*Add function to determine the bitmask of images
*Make background types semi-mixable via “flags”
That about as far as engine enhanements go. I did some various tweaks, but nothing really worth noting. Anything worth noting was probably posted about. An hour or two was spent on preliminary work (idea’s, reasearch, the document with my GID info in it, etc) and art work (which is very limited).
For a more in-depth analysis, go examine the GID 15 category.
Permalink
09.15.05
Posted in ALPHA, Programming, SGE Enhancement at 8:08 pm by Nick
Time: 1.5 hours
Total: 25.5 hours
———————
So I picked up where I left off last night. Mainly speaking I finally made it so the extention and the location would be pulled off, leaving the name. I realize this is hard to understand, but simply put, /images/bg.bmp becomes just ‘”bg”. This is hard coded, however, meaning if I wanted something in /images/backgrounds/bg.bmp then it would become backgrounds/bg, which isn’t totally bad, but there are ways around it.
Also added the PRGW/PRGH functionality to FILE/GENERIC bitmap scripting. Since this also seems to be a murky subject for some people, let me explain what this does.
Earlier I added the ability to specify the screen size in the script. Well, say you want the “bounds” of your background to be that size, and all of your sprites. This would give them full access to the screen. Simply put, its a time saver. Rather then going through and changing the bounds parameters of every sprite and the level as a whole, I just specify I want them to use the program’s width (PRGW) and its height (PRGH) and it does it for me.
I think just about everything that has width/height (save pure bitmaps) now can have the PRGW/PRGH parameters in scripting. If not, it will probably head that way as I find that I need them.
Permalink
Posted in ALPHA, Programming, SGE Enhancement at 12:03 pm by Nick
Time: 2 hours
Total: 24 hours
——————–
What seemed like a few minutes of work turned out to be a rather large head ache. For some reason the GetBitmapDimensionsEx() function stopped loading the width/height of the bitmaps. Now I have to specify to load them from a file -AND- specify the width and height. So I had to go back to the scripting code and rework some things.
Finally after a while I got it to work fine, though I never finished the original task: remove the extension and location of the file from the name (meaning /images/bg.bmp would become just bg).
GID 15 is approaching quickly. Hopefully today and tomorrow I can knock the major things off the todo list and work on a solution to the object problem.
Currently objects are treated like pseudo-sprites. However, now that I have the bitmask code working it should be easy to change it. Also the bitmask library provides a way to draw one mask onto another, which will be perfect for creating my backgrounds.
I’m currently thinking about revising my initial task for this project, which was to enter the Game Gems IV contest. Simply put, the end of that contest is in October, and I doubt I can make a quality game in one month while still dealing adaquately with school and what not.
However, there is a GID every month or so it seems, so I can probably enter many of them in the time it takes to do this project.
My goal now is not to create one nice big game (though I may still), but rather to make lots of fun little ones. The one this weekend should be one of them. Also I have plans for another, which is very similar to the examples I have currently. You try to catch the blocks which dodge your cursor.
Not much else to say or show until the next code export.
Permalink
09.13.05
Posted in ALPHA, Programming, SGE Enhancement at 3:57 pm by Nick
Time: 2 hours
Total: 22 hours
———————–
I decided to try out some more functionality of my scripting system. I ended up with eight sprites with four colors, all blocks, all of which try to dodge eachother! They actually do an amazing job of it too.
Most of the time on this went into cosmetic changes, various cleanup, comments, etc. Lots of ideas going through my head. I will post the binary for the dodging blocks example I mentioned a bit later.
Right now I’m thinking I may pull the level_buf[] buffer out of level.c and give it its own file to save on compilation time. Level.c is the biggest file after all.
Viewable Code -> http://www.nick-cash.com/download/SGE/
Permalink
09.11.05
Posted in ALPHA, Programming, SGE Enhancement at 11:15 pm by Nick
Time: 1 hour
Total: 20 hours
————————
Updated the todo list, so you can find the current code exportation (which will always remain at http://www.nick-cash.com/download/SGE), and any binaries I’ve made thus far.
I’ve updated the collisions one, so the old one is not available. Strangely enough it is 1.5kb smaller then the other I do believe, even though it packs more of a punch. It contains v1.5 of the bitmask collision library, my xlog library (with logging disabled), as well as the new enhancements.
As far as the enhancements go, the smallest block tries to dodge the rest. Yes, it can wrap the screen, and yes, you can drag it if you catch it. Its not perfect AI, but it works well most of the time (it doesnt take into account wrapping the screen). Also, anything you drag will no longer have a velocity, so it wont move. Also, it wont collide with anything. When you let go, its original velocity will take over.
Not a whole lot else to note really. You can see most of my tasks are done off the todo list, so I’m fairly well off for this upcomming weekend. For those who missed that post, I will be participating in GID 15. I will be making a helicopter like game, except you don’t use the mouse, you use the keys, and hopefully I’ll add some interesting functionality to it. I wont use a helicopter either, I’ll be user my classic flying saucer (multicolored!). Note I will use all 24 hours, all of which will count for my project. Wooty licious on a stick. Sure, whatever.
Homework now. That chinese was good, btw.
Permalink
09.10.05
Posted in ALPHA, Programming, SGE Enhancement at 6:47 pm by Nick
Time: 1 hour
Total: 19 hours
—
Did a few things off the todo list, such as adding the PRGW/PRGH functionality to the sprite “bounds” scripting section (yay!). Also made the code reflect the MAXSPEED define, which now limits the speed of sprites. I used to have such a thing, but it somehow got deleted. Anyways, this one is implemented better.
Also made a lot of cosmetic changes. Added a lot of comments, though the functions were fairly self-explanitory (SetPosition…what does it do!??!?!).
I’ll resume work later, but now its time for chinese food. When I get back I’ll do another export and update the code and replace that pesky collisions binary, which is now much better (the smallest block dodges the others!).
Permalink
09.09.05
Posted in ALPHA, Programming, SGE Enhancement at 7:10 pm by Nick
Time: 1 hour
Total: 18 hours
—–
I’m not sure how this one slipped past me before. Last year during LAE I was sure I could script as many sprites as I wanted, and I was right to an extent. I always scripted them and arranged them from lowest Z-Order to highest Z-Order.
Now I’ve fixed it so, if I somehow get out of order (which is likely, no reason to script by z-order), that it will do it correctly, like the real linking function. Sadly, parse_level is not allowed to use the actual function, so I emulate it by hard coding (::sniff::).
For those who don’t know what Z-Order is, which is probably most of you, its when you arrange the list of sprites according to a number. The number is just a way to organize the list (from lowest to highest). So, when you are drawing your sprites, you start from the beginning of the list (ones with the lowest z order) and word backwards. Due to the way graphics work, everything becomes layered. Sprites with a higher Z-Order will be draw last, and thus, on top.
In summary, if you wont your sprite on top during drawing, you want to give him a higher Z-Order, and thus make him closer to the end of the list.
Permalink
Posted in ALPHA, Programming, SGE Enhancement at 6:17 pm by Nick
Time: 1 hour
Total: 17 hours
—
With my current setup you could turn off logging, or even sections of logging pretty easy. However, it spewed both text and XML logs. I only need one, so I went through the code and #ifdef’ed things, making it use one or the other depending on if XLOG is defined.
Permalink
09.06.05
Posted in ALPHA, Programming, SGE Enhancement at 5:52 pm by Nick
Time: 2 hours
Total: 16 hours
—
I recieved a reply to the e-mail I sent. Apparently the site moved and the most current version of the library is 1.5. Woot.
Needless to say I’ve updated and will, consequently, be reuploading the collisons.exe file to corrospond with the changes. Also I noticed I forgot to ifdef a glog() call so it makes log directories and fills it, notifying you of collisions! Whoa!
For the curious, the updated library can be found at:
http://www.ifm.liu.se/~ulfek/bitmask/
Permalink
« Previous entries Next Page » Next Page »