Finally!…the blog gets a facelift.

I’ve been wanting to update the looks of this thing, for like, oh I dunno…FOREVER. Well the time has finally come.

Its a little custom wordpress theme, my first actually. No its not what you would call beautiful, but its more or less what I wanted. Something simple, yet nice to look at( IMO, at least. ) I wanted something dark, but not too drab. Also I wanted something thats sort of serious, but also kind of whimsical at the same time. Sort of like me

So this is the result. I’ll probably be toying with it a bit, but the main ideas are there. The comments are ghetto right now, and yeah chalk that one up to lazyness. The stylesheet could probably be cleaned up too.  It will all get some more lovin’ as time moves on.

Anyways, pretty pleased right now

New year, new directions

Yes, I’m still alive.

Haven’t been too active coding wise, other than putting in some more time with the Boo language( The more I use it, the more I believe that its the best language.  …for me at least  ).

I still have a metric ton of projects sitting around in various states of completion. And probably about 10x as many  still incubating in my head.

Frankly though, I’m sick of it. That, along with the fact that I’ve yet to monetize my skills or work in any significant way, just kills my motivation. It sits like a dark cloud over my head, and it just keeps growing over time.

I can’t emphasize enough, how much this stresses me out. Its been an ongoing cycle of highs and lows, but ugh…I can’t keep operating this way. So I’ve really been taking a closer look at who I am, what I want out of life, and what my goals are. What are my strengths, weaknesses, etc.  …I have a lot to evaluate and work on.

Anyways– Some of my near term goals:

• Giving this blog a little facelift.
• Adding automatic inlining of value type operator overloads to Sharpener.
• Android development seems to be calling to me again. It seems like it might be the best route for me right now.

We’ll see. Down, but definitely not out!

Minecraft inspired renderer

As if I really needed another project on my plate. Oh well.

Work has started on a Minecraft inspired rendering engine. Still very early, but my impatience got the best of me, and I wanted to show it off to anyone who cares.

It resides in my “research” folder, but I would really like to move this into the “production” folder. Time will tell. As for now, I’m scratching an itch, and using it as a distraction from the monotony of my in-production projects.

Announcing Sharpener

Sharpener is an optimizer for CLR assemblies. Its purpose is to squeeze a little bit more performance out of managed code, should you need to do so.

It works at the IL level, and should play nicely with exe’s/dll’s built with C#, VisualBasic.NET, Boo, or any other .NET/Mono friendly language. Its not heavily tested yet though, hence the “should” part

Sharpener is written in C#, and makes good use of the Mono.Cecil library. It is licensed under the very liberal MIT/X11 license. Its basically a “do whatever you like, just don’t misrepresent the original author(s)” type deal.

Current version: http://code.timbarela.com/sharpener/downloads/sharpener-11.11.0.1.zip

For source code, bugs reports, feature requests: http://code.timbarela.com/sharpener

Anyways, the optimization it performs is fairly basic. It tries to replace callvirt instructions with call instructions, which the C# and VB compilers insert for null reference checks. Going off of information on the net, this is worth about 1% performance increase.  Yeah thats not much, but it is an improvement, and it was easy enough to implement, with out any real negative side effects.

The second, more recent feature is a ForceInline attribute that you can mark your assemblies methods with.  Sharpener can then insert the body of these methods at callsites.

Csc.exe at least, appears to be conservative with inlining, leaving it all to the jit. And while apparently the jit’s inlining heuristics have improved, it still sucks to not have control when you need it. But now you have that control

–forceinline is pretty naive in how it patches in the method bodies, so it comes down to how well the jit will clean it up, but the little I have seen so far looks promising.

Again, none of this is tested real well right now. So the jury’s still out on typical gains. This has also underscored the fact that I need to learn x86 in depth. So I plan on spending some time getting my hands dirty with that in the near future. Eek!

Next steps, testing and automatic inlining of valuetype operators.

Pygame Subset For Android.. Again

Ugh. This is my third, and hopefully last post on Pygame Subset for Android. ( I removed the others. )

I’ve flip flopped on my opinion, and now I’m back to square 1. Its a *great* idea, and hopefully it can become usable enough to write a real game with. But as it stands right now, its just far too slow. Its also missing a couple of important features, but thats another story. Anyways, the speed thing is a huge barrier for what I want to do,  and I wasn’t expecting to do anything remotely action or graphically intense. But as a testing the waters type of thing, I did write a little sprite demo. Unfortunately, it chugs along at 20ish fps on my phone, and thats with 1 or 2 things being drawn. The fps drops rapidly as sprites increase.

Long story short, its just not workable for the stuff I’d want to make. Anyways, I’m tired of writing about this thing now…Its a shame really. A total tease, because I’d love to use it!

Update on BlitzDotNet.

Well its been about a year since I last worked on BlitzDotNet. But I’ve picked it up again, and I’ve made a little progress in the past few days. Probably need to rethink things a little more on the compiler front, but working on the runtime is deviously fun.

I’ve now started work on integrating SDL into the runtime.

My first idea for BlitzDotNet was to match the original Blitz pc, and be able to compile most “2D” based programs. I’m starting to discover little differences between Blitz3D and Blitz+ that I never noticed before. On top of that, SDL is handling all the multimedia functionality under the hood, and there are a few items I’m not sure how to map completely into blitz-isms yet.

Basically, I’m still doing my best to meet the original goal, but I’m starting to think BlitzDotNet will be its own unique flavor, so to speak. Some kind of weird hybrid between Blitz3D and Blitz+.  Minus the 3D and GUI capabilities of each.

And maybe some kind of Blitz-to-CLR bridge for interacting with other languages should be thrown in.

And maybe 8-bit paletted mode..

Okay enough for now :]

Zerg: my new game architecture-entity-system-thingy

t some point back in time, I had come across a couple of good articles on structuring your game code. The first was the Guerilla Guide to Game Code, and the second was Evolve Your Hierarchy, by Mick West.

I’m not going to cover the articles, but I will say they both came to me as big “Aha!” moments. I’ve been looking for a good system/method to structure my games around. My game code always seems to get so sloppy, and messy, and ad-hoc.  Even for small things.

Not to mention, I hate having to re-engineer the high level architecture each time I get an idea or want to try something out. I had never been quite happy with any of the setups I had used, so it was always time to reinvent the wheel. Very draining.

new a very long time ago that I needed something I could settle on, and be happy with. Something that was generic enough to be used in all kinds of games, yet not clunky or grossly inefficient.

I’ve been trying to apply the lessons and concepts from those articles to my own work for a long time. I’ve tried different setups based on the stuff in the linked to articles, but never really was satisfied.

But finally…. I have something I’m happy with right now. I’m calling it “Zerg”, named after a certain, fictional space creature that can become a whole variety of different forms. ( Silly? Yeah, but I wanted a name, and not just “Engine.dll” ).

Its written in C# 3.0. Its still really early, and not tested. I need to port both my WIP game’s over to using it.

Granted its just a *very* lightweight framework. It won’t do anything on its own. You still have to provide all the meat and potatoes. But getting past this big (mental?) hurdle, and not having to worry about the previously mentioned issues anymore is very freeing… my coding efforts dropped off to nothing in past months, due to lack of motivation. But right now, I feel excited for whats to come

A random update

Well I’ve dissappeared from blogging once again. Life has a funny way of throwing distractions your way, and I think it  runs in my blood to get easily distracted. So thats still a work in progress for me, personally. ( I am trying though, honestly! )

So outside of some random bursts of coding, I really haven’t done too much in the past few months. In the past few days however, I’ve been ramping up in a big way. Actually I’ve been re-learning Python. I mean, I can use it, and have used it in the past. But right now its about getting really serious with it. Not just knowing it, but really trying to know it at a deeper level. Maybe even be more ‘pythonic‘ if you will.

My initial draws to python remain the same, but the now I’m starting to see it a little bit better. And its a really powerful tool in my mind.

Anyways, where I’m at right now:

• A PC Engine/Turbografx-16 emulator project. Not much to say about this just yet. This is something I’ve been working on, here and there, for a long time now. Its very much a fun + learning project, so I have no problem taking my time with this. Its in bits n pieces currently. I have some of the video hardware emulated, but the whole thing needs TLC. The most useful thing to come out of this is the disassembler which can decode 6502, and almost complete HuC6280 support.  I’ll talk about this more later on
• My Game Development Kit.  Ahh will I ever release this thing? Will I ever complete it? Who knows. Its both something I’m extremely proud of, and totally embarrassed about. Its awfully frustrating to me now, just in how long I’ve been playing around with it. I’m not giving up, I think theres some good stuff to be had, but it still needs a lot of TLC. I’ll talk about this more later on as well.
• Two Games. One overhead arena based shooter that exists mostly in my head( and some quick prototypes ), and a Platformer game that I think has a lot of potential if I can buckle down and keep up progress on it. Both using my afforementioned game dev kit.
• BlitzDotNet. I did make a good amount of progress after the initial announcement. I’d say the parser is about 60% complete. There’s some little things that make the language weird that were tripping me up. I plan on picking this up again sometime soon.

So anyways. Time to get back on that saddle!

And wow… a lot of spam comments! I guess thats what I get for not maintaining my blog enough. One more reason to stay on top of things. Therefore I’ve decided to dedicate at least, a couple hours a week to blogging. Even if its mostly just maintenance stuff no one sees.

Til next time, whenever that may be!

Announcing BlitzDotNet.

BlitzDotNet is a BlitzBasic compiler and runtime library for .NET and Mono.

Its a little early in development to be making any grand announcement, but things have really been coming together nicely up to this point. ( And I’m having a lot of fun too! )

I’m working on it in somewhat steady bursts. Its all written in C# 3.0, with IronPython proving itself quite useful for testing stuff.

Right now BlitzDotNet consists of:

• The Core Runtime. A good portion of the non multimedia functions are in place. This mostly involved mapping blitz functions to the BCL of  .NET.  Its not strictly 1:1 however, somethings required a little bit of thought. Nothing too hard mind you.
• A BlitzBasicLexer.  It seems to perform very nicely, but I don’t really have any way to benchmark it to something else. For now, I’ll just go with what I see. I’m on an ancient computer, and its able to rip through decently sized folders of blitz source( The Blitz3D samples/games, AlienBreed project, and my own giant mess of accumulated code ). I also built a quicky syntax highlighting test in winforms.   ( This was just a dirty, somewhat real world test, not a serious attempt at an IDE  )

Next Steps:

• The Parser. A hand crafted, top down recursive descent parser. Why? Because thats just how I roll.
• The Runtime. Needs more TLC. There’s still some odds and ends that need to be dealt with. Not going to implement the multimedia functions just yet, as I’m having some inner debate on the direction or how far I want to go with this.  ( See below )

My main plan was/is to create a BlitzBasic implementation for the CLR. I mean the original BlitzBasic as launched for the PC. Not Blitz3D, not BlitzPlus. Not BlitzMax.

Also, I don’t want to introduce any special syntax for working with the BCL. Maybe some built in commands for basic things, or an include “clr.bb” similar to IronPython’s clr module. But it won’t be able to produce dll’s for other languages to consume. My big goal is that it just works with 99.9% of all the bb code out there.

I figure all the multimedia functions should be mapped to SDL. But now I wonder about other possibilities. Should I go for the full Blitz3D command set?  Or at least, go for hardware accelerated 2d through OpenGl. I could use my own game framework( which will be announced at a later time ) for these duties. Maybe Xna? Blitz on the Xbox360 could be pretty cool. Anyways, these are things in the back of my head, but for now I’m carrying on with my original plan.

So why do this?

Most of all, because its an itch of mine. I’ve toyed around with compilers a little, and even got a false start on a managed version of blitz a long ways back. I feel compelled to do it. Its interesting, a challenge, an exercise. As well as something I can just say “I made that.”, or show off to potential clients and employers .

So its not entirely selfless. But, I’ve also thought about some of the cool potential uses for this. There’s a lot of games made in blitz, that will forever be stuck on windows. By creating a blitz implementation on the CLR, a lot of software, should be able to run in a lot more places, (almost) instantly. iPhone anyone?

Even with BlitzMax being the preferred tool now, its still stuck on Windows/Mac/Linux. People are still asking for an ARM port.  Mark’s one person, vs an army of people working on .NET or Mono.

What about keeping the language alive? Just for nostalgia, or future generations? I still think blitz is an absolutely great way for beginners to get into programming. Think about how many more eyes could potentially see blitz if its on a big platform. Not hating on Visual Basic, but I honestly think for a beginner, BlitzBasic can be a much better experience than VB tied to Xna/OpenGl/Insert Random Game Engine Here.

The way .NET works makes code sharing so easy. Hopefully the individual components that make up BlitzDotNet can be of use to others in some way.  IE, making a Blitz IDE, or code analysis tool, or maybe even turning it into a DLR scripting language

So anyways, I’d like to gauge both the interest level for this, as well as start getting some input from the blitz community. Its still early enough, that (hopefully) we can avoid anything that will be too hard to change later down the road.

I do plan on releasing this as an open source project, just not sure when that’ll happen. Sooner than later I imagine.

Blog Reset.

Well I managed to screw up my old blog during an upgrade, and just hadn’t gotten around to doing anything about it until now. I’m sure all 2 of you who visited my blog were just devastated

Anyways, it really was for the better. I wanted to cram all my thoughts and hobbies into one superblog, but I now believe having multiple, on topic blogs will work much better.

So here it is. My blog on all things relating to programming and game development. I plan to throw in a few other related subjects, but I think it should be quite obvious what the focus is.