The 30k blog where you can find updates on projects, future ideas and plans and news in the world of computers/programming!
Not to mention you get to hear MY opinion, which I'm sure you all care about...
|Posted on May 14, 2012 at 4:25 PM||comments (0)|
It's finally here. The official, supported version of Java is 1.7 (or JRE 7 for marketing).
Some cool new language features have been introduced for the programmers like myself (and perhaps some of you?), and some solid security and performance improvements for the end user.
I will try to take advantage of this new platform here on this site ASAP, but in the meantime, I still recommend going and picking it up if your Java auto-updater doesn't do it for you:
|Posted on April 24, 2012 at 6:10 PM||comments (0)|
I'll start with the bad news. Surviving Dead has been placed on hold. Why? The engine just isn't good enough. GTD is supposed to be just a base that provides some task distribution tools. The implementation I wrote for SD sucks. It's nearly impossible to design smooth collision detection when you're using images (all rectangular or elliptical bounds).
The good news is, I'm not giving up on game programming. In fact, I'm really excited about this new project I'm launching under 2DX. I'm writing a new game engine called Snapdragon 2D that I will use in the future to make 2D games. I'm focussing entirely on the engine so that I can get all of the low-level stuff out of the way now and focus more on game design later on. This engine will be 100% re-usable and 100% open source (part of 2DX).
|Posted on March 28, 2012 at 12:20 AM||comments (0)|
I don't think I have come out and actually said this yet... but I am developing a mobile version of Datawire for Android devices.
Don't expect it to look very familiar... with the exception of maybe the main screen. The Android version has been built fresh from the ground up with ZERO code borrowed from Datawire, and I intend to keep it that way for several reasons:
1) Obviously, standard Java front end code written using Swing for desktop computers won't work on Android. Android uses it's own API for ALL aspects of the system regarding the UI.
2) Rather than making a mobile version of Datawire with all the current functionality, I decided to take the initiative to go ahead and write the Android "port" (not really though) as though it were Datawire 2.0. So, a lot of the back-end, networking code being written for this app will be used in the next release of the standard, desktop version of Datawire. I've taken great care to make the code as "modular" as possible, separating UI stuff entirely from networking, being linked only by interfaces that define how they communicate (which is interchangeable between platforms). There are a few Android system-specific things in the back-end code I will need to change in the port back to the desktop version, but mostly, it's re-usable.
3) 70% of Datawire's current codebase and design sucks and needs to rebuilt anyway.
I regret to inform you that, although for my benefit, the Android version will NOT be free. However, it will be very cheap, so don't complain. I'm thinking either $0.89 or $0.99. Very inexpensive and affordable, but it gives me a chance to make some money off of it (which will help with development).
Datawire 2.0 for Windows/Mac/Linux/yadda-yadda WILL STILL BE FREE. Don't worry about that. I'm not going to put the time or effort into setting up a secure online transaction system and lockdown my software. Meh. Not worth it.
The Android and desktop versions will be able to communicate with each other as though they weren't even on different devices. A PC can host Android devices and an Android device can host PCs. No kind of special treatment will be required for users. The client/host will just be another person.
I'm putting a lot of effort into this... so I hope it works out well....
|Posted on March 9, 2012 at 12:05 AM||comments (0)|
I've been meaning to work on implementing some sort of system where you guys can actually submit code changes to me for 2DX (if there is actually anyone registered who can/cares).
It might be a waste of time, but who cares? That's what I do right?
I'll get around to it eventually. And by eventually I mean soon.
Also, I will start working on the adition of a new general purpose, lower-level (but still 100% Java based) graphics engine soon. Pixels ftw.
|Posted on February 15, 2012 at 8:00 PM||comments (0)|
I have launched a new project under the umbrella code-name "Project Recensus"
Let's just say a new innovation may hit Android market sometime soon.
And ironically... it will be Datawire 2.0... but not actually. You get what I'm sayin'?
|Posted on February 7, 2012 at 5:05 PM||comments (0)|
I lied. Datawire 2.0 will use primarily NIO, and here is why:
Sticking to pure blocking I/O would mean launching a new thread to go listen for protocol signals from each client. This is an issue primarily with scalability (not so much speed). For a P2P program such as Datawire, if a host decides he wants to have 20 people all in one lobby, that's 20 threads performing I/O operations at one time.... quite a bit of resource usage.
NIO enables me to have Datawire monitor all of the clients from one Thread and handle each client request far more efficiently through the use of Selectors.
So, the networking protocol and data engine will be NIO based. The file I/O may or may not be. I'm not totally sure right now. There will, however, be some traditional I/O still mixed in, as it often allows for much more maintainable and easy-to-work-with code.
Cause obviously you care about all of this right?
|Posted on February 5, 2012 at 5:25 PM||comments (0)|
Project Recensus is underway (codename for Datawire 2.0 :D).
Want a preview of the new lobby? Here is a Paint.NET created plan:
One small change to the plans for Recensus...
The networking and I/O code will most likely be based on the JDK 7 I/O framework rather than the JDK 7 NIO framework because current testing is showing that I/O performs better.
Development shall continue.... and we shall see.
|Posted on January 24, 2012 at 10:35 PM||comments (0)|
Game programming is difficult. And by that I mean REAL game programming. Not Flash.... not Blender... I mean sitting down and coding a game. Every single game developer deserves our respect for taking on the task. Every aspect of the game involves huge amounts of logic, graphical code (that's the worst) and more. It's hard for most of us to realize how much work a game (especially a true, 3D one) really requires.
I have, am, and will continue to be reminded of this as I continue my own goals in this field. I'll be honest however, Surviving Dead won't be the most beautiful, smooth or well polished game you've ever seen. In fact, it might even qualify as mediocre.
It's my first game, so I don't have high hopes for an outstanding result. That is mostly due to one simple thing:
The game engine
I made the decision when I began development on this game that I wouldn't deal with reading, rendering and manipulating pixel data directly. I felt that I would be setting a task I'm not ready for. What's the trade off? Accuracy, precision and control.
The Surviving Dead engine is based on the 2DX Graphical Task Distribution Engine (GTD). GTD is designed to be high level, simple and easy to implement. It functions by centralizing the task of rendering 2D objects on screen, forcing every Java Object that wants data rendered to implement the Drawable interface and register with the engine. It calls the draw(..) method and passes the centralized Graphics2D object that everything is being rendered upon to be utilized.
Why this engine is good:
-GTD provides a simple, easy-to-manage way of animating, through distributing the render graphics to every object that wants to draw on them.
-It can be used for more than just games. The engine can be chained to any Grahpics2D object, even if it's some arbitrary BufferedImage. It's really easy to use this engine for simple animations, image creation, and structured graphical task execution.
Why this engine is bad:
-While GTD provies a certain amount of centralization with task distribution, it also decentralizes the act of rendering graphics. Every Object is responsible for rendering its own data, internally oblivious to other Objects and making it a lot harder to manipulate things such as lighting/effects.
-GTD is designed as a high level solution to animation/graphical rendering and therefore does not work well with attempting to manipulate individual pixels. The only way this is possible is by creating BufferedImages and manipulating their data, which can take a significant toll on performance.
-The nature of iterating through tasks limits the engine from being able to handle a high volume of tasks or objects that need to be rendered without decreasing frame rate and general program performance.
What can you expect from Surviving Dead? Well... due to the nature of the GTD engine, most of the rendering is done via BufferedImages, which means the most noticeable defficiency you may notice is collision detection. It's far from perfect. I will keep trying to improve it, but it will never be as good as a game that handles graphical data pixel by pixel.
Will the game still be good? I hope so. I will try as hard as I can and leave that for you to decide.
|Posted on January 23, 2012 at 5:55 PM||comments (0)|
I feel the need to apologize for an embarassing and rather significant error that has been in Datawire for quite some time now that I never realized.
The auto-detect rescale code only worked on the frame... so the rest of the stuff remained the same. So users working on smaller screens had completely wacked out, squished GUI layouts. I simply removed the code and reverted back to using a constant 600x525 screen size.
There is no point in trying to auto-rescale the GUI because 98% of the components have sizes that are set as straight up numbers in the code. No organized variable system... just arbitrary numbers. One of the many problems with the Datawire GUI code.
This is an issue I am taking into account now with future applications. GUI code has been a hit/miss thing with me since the beginning. I'm getting better, but there's still much for me to try and improve on.
Please... if there are any horrible problems existant when you run one of my programs on your system that I don't know about... contact me via the forums, error report or support page.
One the greatest things about Java is the ability to deploy on all platforms with ease. I want to make sure I hold true to that, and design dynamic applications that wiill adapt to YOUR needs... not the other way around.
|Posted on January 14, 2012 at 1:55 PM||comments (0)|
JK. It's just me talking. Although if you want to consider me your neighbor, be my guest.
Surviving Dead -
Working on it. Writing/debugging the generation code. I've been putting off making the graphics, but I will have to eventually...
Datawire 2.0 -
Haven't touched it in a while. Not in much of a rush since Java 7 still hasn't been officially released as the end-user standard version yet.
I managed to put out another beta build on the Beta Releases page. Added several featuers and fixed several bugs. I'm still working to improve it and make your experience with it as easy and convenient as possible.
I'm developing 2DX almost hand in hand with the game, Surviving Dead. I haven't put a whole lot of focus on it recently, but since SD uses it, whenever I find a problem to fix or feature I really want to add, I do it. Not sure when I will actually release a new Alpha build though...
N.B. I moved a couple classes and changed some variable/method names again. Sorry, but remember this is Alpha. I can do that
JavaCalc 3.0 -
I haven't decided whether or not I'm going to attempt this. If I do, it will be yet ANOTHER rewrite of the entire codebase. I recognize that the GUI code really sucks... and there are several weird quirks in the way it behaves that can be annoying.
If I decide to start building it, I will also be (most likely) trying to make it take straight up input (not only buttons). Essentially, it would function much more freely like WolframAlpha or TI-nSpire.
I actually do think a free, offline calculator that uses that free input system (and could possibly use nice formatting unlike Wolfram; don't get me wrong I love Wolfram :D) could be very beneficial for some people. However, a lot of the functions and capabilities of nSpire and WolframAlpha are certainly far beyond my abilities. It would still be limited to the current functions of its Math engine.
Ok.... well now that that is over... have a nice day, week, month, year, lifetime, etc. And keep visiting (and/or give me feedback!).