The house I grew up in about 85% of my life is falling apart. It's a real shame to think house the house used to look and how much things change over time.
A year ago, the roof collapsed in my mom's room, and eventually the roof collapsed in the corner of the kitchen too. A lot of furniture has been ruined since that time. You can't hardly breathe in the house anymore.
Today, me and my brother spent about 4 hours straight getting stuff out, because the roof is finally being redone. We took the water bed apart, tore up all the carpet, shoveled the drywall and other stuff laying in the floor, and basically moved everything out of my mom's room. We also moved some things out of the kitchen, but we were tired after 4 hours of hard work, so we called it quits. Plus, it was getting late (I got home at 10:00).
Eventually, everything in the entire house will have to come out since the entire roof will be changed. It's not just shingles that are changing, it's all the wood as well. I hope eventually we can get that house looking nice again. My dad criticizes me and my brother for not helping out enough, and he's right to do that. I do wish my dad made attempts to change the roof all those years it leaked. I understand it's expensive and such, but it was something that always got put on the back burner. My dad did a lot of hard work, so I'm not trying to say he's lazy by any means. I do think however that he ignored the problem when he could have done something about it. We didn't do anything to fix the problem 15 years ago, so now we're faced with the problem in a far more dramatic way now.
Right now, my legs and back are killing me. My shoes and socks are off because they are covered in mildew. I took a shower because I needed one desperately after being in that horrible environment for 4 hours. It's good to finally sit down.
I enjoy sharing with people my dynamic life. Here I will share my projects, experiences, and ideas. I normally update a couple times a week, so check back often!
Wednesday, November 29, 2006
Monday, November 20, 2006
The Slap Bet
Do you know what a slap bet is? See it in action -- http://www.youtube.com/watch?v=NiqTCiIpxmU. Trust me when I say it's legendary! The clips come from "How I Met Your Mother". It might make a bit more sense if you saw this episode, but I'm taking my chances by showing it to everyone anyway.
Friday, November 17, 2006
Drawing Library Under Development
I have been working on several test programs in my free time to try out some new ideas I have for my ProSonic game engine. ProSonic has become increasingly difficult to update, so I have been rewriting some major portions of the engine's code. As I said before, this is overdue. With my drawing library in development, I should be able to support the features I want without having massive amounts of clutter. The only down side to this is rewriting the code might actually cause the engine to run slower on old computers. I have always had the benchmark set at 60fps on a Pentium II at 400MHz. There's still a chance I can pull it off, but there will no longer be any guarentees.
I have also redesigned the background filters. The old concept was a really good idea, but because the old drawing code was so messy, I found it hard to get background filters working exactly how they were supposed to work. So since I'm doing a rewrite of the drawing code, I figured I might as well update some file formats to support some new features, and the background filters have certainly been enhanced. These background filters are called "composite filters".
The idea of a composite filter is to mathematically break up the background into seperate parts. These parts are called "cells" and have many properties associated with them. Ultimately this will allow background effects in ProSonic like the ones in the original Sonic the Hedgehog games, but with absolutely no programming required. Cells can move on both the X and Y axis at any speed. They can also auto-scroll, grab pixels from another area of the background, and use distortion filters. The composite filters are different than they were before because instead of breaking up the background by horizontal lines only, the background is broken up in horizontal and vertical lines. This means you can carve out a square area and have that square move freely up and down across the background without anything beside it attached.
As usual, this probably sounds like hype. It is hype -- I like talking about what I'm doing for the engine and about all the different ideas I have for it. If I happen to finish the drawing code rewrite before December 15th, I will release a public demonstration of the engine. December 15, 2005 was when I first began writing ProSonic. I feel a 1 year mark is appropriate to release something. If I don't get the drawing code rewritten by that date, I still have something else I'd like to release.
Also, I still haven't forgotten those questions. I will get to them, I promise! Just give me more time please.
I have also redesigned the background filters. The old concept was a really good idea, but because the old drawing code was so messy, I found it hard to get background filters working exactly how they were supposed to work. So since I'm doing a rewrite of the drawing code, I figured I might as well update some file formats to support some new features, and the background filters have certainly been enhanced. These background filters are called "composite filters".
The idea of a composite filter is to mathematically break up the background into seperate parts. These parts are called "cells" and have many properties associated with them. Ultimately this will allow background effects in ProSonic like the ones in the original Sonic the Hedgehog games, but with absolutely no programming required. Cells can move on both the X and Y axis at any speed. They can also auto-scroll, grab pixels from another area of the background, and use distortion filters. The composite filters are different than they were before because instead of breaking up the background by horizontal lines only, the background is broken up in horizontal and vertical lines. This means you can carve out a square area and have that square move freely up and down across the background without anything beside it attached.
As usual, this probably sounds like hype. It is hype -- I like talking about what I'm doing for the engine and about all the different ideas I have for it. If I happen to finish the drawing code rewrite before December 15th, I will release a public demonstration of the engine. December 15, 2005 was when I first began writing ProSonic. I feel a 1 year mark is appropriate to release something. If I don't get the drawing code rewritten by that date, I still have something else I'd like to release.
Also, I still haven't forgotten those questions. I will get to them, I promise! Just give me more time please.
Sunday, November 12, 2006
Programming & Progressing ProSonic
I've been able to work more on ProSonic lately. I have completed the new PZF format and have successfully written the library to load, save, and compile PZF files. This is a major step in the development of this project because as I've said before, PZF files are part of the backbone of this project. They contain all the level data like object layout, block-maps, tile-maps, palette, and so on.
On top of that, I have designed a sprite format to be used by ProSonic. Originally I had stated that games using 16-bit color wouldn't be able to load certain types of data from 8-bit color games, and vice-versa. I can't guarentee that won't still be the case to some degree, but I can safely say the new format for sprites is the only format that will be used by the engine. It will work in both 8-bit and 16-bit color modes. It has a sophisticated design that also includes features such as built-in color cyclers and multiple palettes that can be activated on a pixel-by-pixel basis. This will simplify development so there doesn't have to be a standard "reserved" set of colors that are always in the same place in every palette. My format allows ProSonic to locate the colors used for the image and draw it accordingly, regardless what the color indexes are. Of course it also contains data specific to 8-bit color mode so it automatically knows what index it should search "first". And if a color isn't found, ProSonic will grab the closest color to the one it's looking for.
I will also be writing a library for drawing the sprites and tiles because it has become too complicated to rip code from the engine and use it in an editing utility. The problem is I always find myself searching through the code for incompatibilities to work out so the code works the way it should in the specific utility I'm using it in. If the code gets updated, I have to update it in every utility. So a library specific to graphics-related operations is essential.
Once I get all this kind of stuff sorted out, I can get utilities out much quicker and make developing ProSonic less painful. As long as I have the time, I am committed to continuing ProSonic and making it people's choice for a game development environment. I know a couple people don't take me too seriously because they either have something against me, or they simply need interactive proof. I'm trying to get there, but every project needs to go through a bit of a clean-up period sooner or later.
By the way, I haven't forgotten about those questions. I just haven't quite gotten around to answering them yet. I will do the deed, I promise.
On top of that, I have designed a sprite format to be used by ProSonic. Originally I had stated that games using 16-bit color wouldn't be able to load certain types of data from 8-bit color games, and vice-versa. I can't guarentee that won't still be the case to some degree, but I can safely say the new format for sprites is the only format that will be used by the engine. It will work in both 8-bit and 16-bit color modes. It has a sophisticated design that also includes features such as built-in color cyclers and multiple palettes that can be activated on a pixel-by-pixel basis. This will simplify development so there doesn't have to be a standard "reserved" set of colors that are always in the same place in every palette. My format allows ProSonic to locate the colors used for the image and draw it accordingly, regardless what the color indexes are. Of course it also contains data specific to 8-bit color mode so it automatically knows what index it should search "first". And if a color isn't found, ProSonic will grab the closest color to the one it's looking for.
I will also be writing a library for drawing the sprites and tiles because it has become too complicated to rip code from the engine and use it in an editing utility. The problem is I always find myself searching through the code for incompatibilities to work out so the code works the way it should in the specific utility I'm using it in. If the code gets updated, I have to update it in every utility. So a library specific to graphics-related operations is essential.
Once I get all this kind of stuff sorted out, I can get utilities out much quicker and make developing ProSonic less painful. As long as I have the time, I am committed to continuing ProSonic and making it people's choice for a game development environment. I know a couple people don't take me too seriously because they either have something against me, or they simply need interactive proof. I'm trying to get there, but every project needs to go through a bit of a clean-up period sooner or later.
By the way, I haven't forgotten about those questions. I just haven't quite gotten around to answering them yet. I will do the deed, I promise.
Thursday, November 09, 2006
PZF Compiler in Action
I have a half-way working PZF compiler. What it does so far is read text files to store zone names, the number of acts, the number of stages (previously called "timezones"), and various stage-specific data such as level size, starting position, stage music, and so on.
The PZF compiler doesn't import data files yet, and it doesn't write the PZF file to the hard drive. Instead, what it does currently is compile it into memory so it is ready to be read through the game engine. This compiler will also replace the PZF file editor I had planned to do in Visual Basic. Although this isn't as user-friendly, it will be easy enough for most people to use. Hopefully I will be able to encourage others to help me write better tools for ProSonic, and that's one reason the PZF functionality is all programmed in a library that can be easily attached to any program.
PZF files are the back-bone to my ProSonic project because they consist of all the data required for the game engine to load a level. The new PZF format is easy to work with in comparison to the old PZF format. I am going to change it even further because the original plan was to limit files (that is, data files within the PZF itself) to 1MB in size. With the recent plan to allow game designers to have more tiles and blocks, 1MB won't be enough to support what I am aiming for. Instead, the file limit will be 16MB. The PZF file as a whole was supposed to be limited to 256MB, but this will get bumped up to 4GB because of the change to the size limit of data files. Some people may not understand exactly why I impose limits like these -- I do so to conserve space that will probably never be used for anything anyway.
The PZF compiler doesn't import data files yet, and it doesn't write the PZF file to the hard drive. Instead, what it does currently is compile it into memory so it is ready to be read through the game engine. This compiler will also replace the PZF file editor I had planned to do in Visual Basic. Although this isn't as user-friendly, it will be easy enough for most people to use. Hopefully I will be able to encourage others to help me write better tools for ProSonic, and that's one reason the PZF functionality is all programmed in a library that can be easily attached to any program.
PZF files are the back-bone to my ProSonic project because they consist of all the data required for the game engine to load a level. The new PZF format is easy to work with in comparison to the old PZF format. I am going to change it even further because the original plan was to limit files (that is, data files within the PZF itself) to 1MB in size. With the recent plan to allow game designers to have more tiles and blocks, 1MB won't be enough to support what I am aiming for. Instead, the file limit will be 16MB. The PZF file as a whole was supposed to be limited to 256MB, but this will get bumped up to 4GB because of the change to the size limit of data files. Some people may not understand exactly why I impose limits like these -- I do so to conserve space that will probably never be used for anything anyway.
Tuesday, November 07, 2006
ProSonic Still Going
I haven't talked about ProSonic much lately, and certainly I have made fewer posts in my blog lately. I have done only a minimal amount of work on ProSonic in the past week because college is my highest priority right now.
With the release of a new Sonic the Hedgehog 2 beta version, it is up to me to make sure my ProSonic level importing tool (known as "LIMP") is updated to support this newly available version of the game.
I've also only recently been thinking about some ideas to allow game designers to choose how many tiles and blocks they need for each level. So instead of being limited to 256 tiles and 1024 blocks for each level, maybe you need more for a particular level. Perhaps you don't need as many for another level. So I'm thinking of allowing multiple formats of tile and block files. Game designers could choose from 8 up to 2048 tiles, and from 256 up to 65536 blocks. This would allow designers to conserve space, and it would also allow them to have more level material available to them if the current limitations are too strict.
Finally, the PZF format is still being worked on. A programming library is being developed so other people can develop ProSonic tools that may require reading and writing PZF files (e.g. level editors). This library is used inside the ProSonic engine code itself, so it is very flexible and will allow programmers to work with PZF files easily without having to rip anything out of the ProSonic source code.
With the release of a new Sonic the Hedgehog 2 beta version, it is up to me to make sure my ProSonic level importing tool (known as "LIMP") is updated to support this newly available version of the game.
I've also only recently been thinking about some ideas to allow game designers to choose how many tiles and blocks they need for each level. So instead of being limited to 256 tiles and 1024 blocks for each level, maybe you need more for a particular level. Perhaps you don't need as many for another level. So I'm thinking of allowing multiple formats of tile and block files. Game designers could choose from 8 up to 2048 tiles, and from 256 up to 65536 blocks. This would allow designers to conserve space, and it would also allow them to have more level material available to them if the current limitations are too strict.
Finally, the PZF format is still being worked on. A programming library is being developed so other people can develop ProSonic tools that may require reading and writing PZF files (e.g. level editors). This library is used inside the ProSonic engine code itself, so it is very flexible and will allow programmers to work with PZF files easily without having to rip anything out of the ProSonic source code.
Subscribe to:
Posts (Atom)