Last Login:
October 20, 2014


User Profile

Hits: 105,146
Joined August 08, 2010
Games (10)

Game Music Player
October 10, 2011
August 01, 2012
In a word
August 10, 2010
October 07, 2010
Flood the mines Demo
November 12, 2010
January 24, 2011
Velocite R
April 12, 2011
Shinsetsu Ninja
February 18, 2013
Walk of Darkness Demo
November 15, 2013
Project Phoenix
April 30, 2014
Examples (1)
Favorite Users

Shop Talk
Posted on October 16, 2014 at 14:39

Caution: This blog contains traces of stupid. Read at own risk

I work at a PC shop. That's a bit of a vague term, and possibly an incorrect one.
To best describe the business, I'd have to call it a "Repair/Retail/Internet Cafè/Scapegoat/Printer/Contractor/Graphic Design/Web Design/Help my internet broke" Shop or Call Center.

I work the typical 9 to 5 shift, and man the shop on my own for 90% of the day.
My boss is on callout for part of the day, and working her other job for another good portion of it.

So yeah... it's a nice little shop. We stock a lot decent retail goods; things like flash drives, keyboards, webcams, speakers, ink, etc...
And of course we do repairs. That's officially my job, though I do everything else too.

Naturally, some of the repairs/requests that customers bring to me are absolutely ludicrous; stressful, but funny when looking back. Here's a couple of anecdotes.

A+ 101: Lubricating your Hard Drive

So, one day this guy walks into the shop and tells me that one of his HDDs stopped working suddenly.
I asked him what happened prior to the failure. He described to me that he thought it was making too much noise (You know the noise those slightly older IDE drives make when they're reading/writing data), and that he tried to fix it.

Yeah... I asked him how he fixed it.

He "fixed" it... by drilling a hole in the motor casing and putting boat engine grease into the hole.
What I wonder is... why did he even have to ask...

Multi-core processing on the cheap

Let's keep this short...
Did you know that apparently 1 out of every 2 people in this town cannot legitimately understand why soldering a bunch of processors on top of each other won't work? (And didn't work, in one guy's case).

Bucket Computer

This one was from today. Around 5 hours ago, to be precise. A guy walks towards the shop with a plastic window-washer's bucket. All I could see in it was a damp looking rag, and I thought he was... well... a window washer, coming to ask if our window needed cleaning (We get a lot of hawkers and such).

Then I saw the power cables coiled on top. That was his 'machine'. The rag was soaked in cooking oil (There's a common myth floating around that submerging or otherwise subjecting your PC to cooking oil will cool it down. It works, but will leave your PC smelling rancid after a while, will leave a slimy residue... and has the potential to build up more heat than you normally would).

Anyway, yeah. Bucket PC. No, it wasn't working. No, he wasn't here to have us repair it... he wanted to sell it to us...

Grease makes things go faster, right?

Is your computer feeling sluggish? CPU slowing down? Never fear! Just apply a generous coating of engine grease to your RAM, CPU and GPU, and never worry about your computer being slow again!

This is another one I've seen relatively often. Vaseline is another lubricant of choice, and some of them have a spritz bottle of cooking oil they use.

Pro Overclocking

This one guy... decided that the best way to speed his PC up was to replace each capacitor on the motherboard with the same high-voltage ones found in PSUs.
According to him, this was 'overclocking'.

Oh, I should probably mention that in all of these encounters, the customer proudly explains their methodology (And shattered logic), then ask "So why isn't it working?".

This is why I'm on anti-anxiety medication...

"I made it fit, so why doesn't it work?"

I encounter, and replace, several varieties of RAM chips, the most common being the DDR2 variety.
But what happens when somebody decides that DDR/SIMM/Whatever ought to fit in <insert slot here>.
One sharp/abrasive implement and a trip to Your Friendly Computer shop later, and I'm again hearing the "So why isn't it working?" line...

This also happens on occasion with AGP/PCI-E graphics cards, and processors.

Well that's enough of that for now

Writing these is both funny and depressing. Depressing because I'm actually having to deal with this on a near-daily basis.
But hey, at least I get paid for it. :P

In other work-related news...
I have an old Pentium sitting around, fully intact. In fact, the inside of the case is the cleanest PC I've ever seen. Slight layer of dust, but the board (A 1996 Intel board), is still shiny and clean.

Naturally, the machine is, for all practical purposes, pretty useless. That's no deterrent to me. My boss has approved a long term project wherein we install DOS or Win98 on the thing, buy some joysticks and a coin box from a company in Cape Town, and build an Arcade Cabinet; Old versions of MAME run pretty well on old hardware :P

We're also planning on moving two of our machines near the front of the shop, on a long bench-table. These particular machines have a few free games installed (Red Eclipse, for instance), and a few classics (Doom, Quake, Quake 2, Unreal Tournament).
Not many people stop by to use our internet services... but we're literally right next to a school/high-school, and hordes of the undead little buggers walk past our doors every day.
We plan on setting up a few LAN tournaments with small prizes; those machines are our 'base' machines, and they can bring their own.

If that gets big enough, we might plan a bigger tournament at the town hall; my boss is a trained event planner/coordinator, and we could potentially make a pretty big deal out of it :P

On a completely different tangent...
Objects of interesting lying around our shop:
> An old Yamaha XG sound card. In working condition.
> An ancient scanner. It's the size of a big office printer, though flatter, yet it can only scan A4 pages (At around 80DPI).
> Mount Oki. For some reason, we have a pile of discarded OKI printers in the back of the shop.
> 22 3 1/2 inch floppy drives. Am tempted to make a robot out of them.
> 8 CRT monitors, some of them are huge. Am planning on using one of them in conjunction with one of our crappy webcams to make a monitoring system of sorts.

Well, that's enough outta me. I'll probably have tons more stories in a few weeks. Things get pretty crazy at work, with great regularity...

I've now seen everything...
Posted on October 09, 2014 at 02:53

Minecraft 1.8. Have you guys seen what's possible with Armor stands?

Gotta run to work, but take a look at this :P

Fun with Windows 10 (Technical Preview)
Posted on October 02, 2014 at 12:00

So Microsoft Announced Windows 10 a couple of days ago.

That's right, not 9. 10.

They released a Technical Preview for "IT Professionals" and suchlike yesterday, and I signed up.
Downloaded the ISO last night, installed it this morning... and voila:

Dunno if that embed is gonna work. I'm trying OneDrive out, as I haven't installed Dropbox yet.

Here's the new Start Menu, if anybody is interested:

One of the first things I noticed is that Win10 doesn't force you into the Start Screen. It's still around, if you choose to activate it, but isn't the default/imposed setting now.

Metro apps don't run in fullscreen, and instead start maximized and can be resized/moved like any normal Window.

Haven't had any driver issues, with the exception of the generic "Tablet Pen" drivers that were installed for my tablet. Basically, my tablet is one giant "Reset PC" button at the moment :P

On the installation front, installing was smooth, allowed me to install to a partition easily, and dual boots perfectly.

I'll add more pictures and stuff if I feel like it.

EDIT: Yeah, OneDrive doesn't like linking. I'll update the images when I've installed Dropbox.
Dropbox installed and images fixed.

Mega's sketch collection
Posted on September 30, 2014 at 14:22

Figures I'd start one of these; I have no excuse now that I have a tablet :D

So far, it's proven to be a joy to use. All the benefits of using an actual pencil and paper, but with the undo feature a computer provides.

I'm thinking of sketching something on a pretty regular basis. Tonight I did this:

And last night I did a little cartoon dog :P

I also discovered that I can play Solitaire quite effectively with the tablet. I was critically bored while waiting for something to finish downloading.

More images to come.

Obligatory Megaman Fan-art:

S4D Mini Progress Reports
Posted on September 20, 2014 at 14:28

This blog is for posting small bits and pieces of progress you've made; anything that you feel doesn't warrant an entirely new blog.

And try to comment on other people's work a bit too! Feedback is going to be very useful during the course of this competition!

Pre-comp Preparations
Posted on September 15, 2014 at 05:51

There was no work for me today, so I decided to start thinking about what I'll be doing for the comp in a more serious way.

I already have the basic idea. I'm making a platformer by the looks of things... but that's OK. It's been ages since I've made one, really.

I'm making a few decisions early on that will affect my work greatly later on. One of these is to not talk about the game itself.
I'll be releasing screenshots, talk about the engine, programming and so on... but I want the game itself to be fresh on release, and not hyped up.

I have three engines to choose from. Exile Engine, Game Maker and Unity.
I've decided to steer clear of Unity for this competition; its 2D functionality is pretty bad, and I don't have the time to invest in coding the functionality I'd be needing.

Game Maker and Exile... both have pros and cons.
I always want to try work with my own engine... but I always seem to have more to add to it; I never seem to be able to finish the damned thing.

That doesn't mean its unusable. In fact, I gave it a bit of a test drive yesterday.
While some of the 2D functionality has been ignored for a couple of years in lieu of the 3D features, enough functionality exists that I can probably put a game together in short order.

On the other hand, there's Game Maker.
It's pathetically easy to use... and incredibly easy to break. While it has a good focus on 'rapid' development, it also has some horrible quirks that I keep on running into when creating a game.

The short list includes: Scaling, audio, room editor and collision detection.

Anyway... my plan is to see what state my engine is in by Saturday. If it's not in a worthwhile condition, I'll use GM from the outset.
There are a few minor fixes and features I wish to add to my engine for it to be considered 'usable'.

This includes:
> Fixing some of the 2D code to work again. Not too much trouble.
> Add scaling properties to config files.
> Switch to a key/value pair based config file.

And that's about it. Nowhere near as much as I had initially thought.
Unless I factor in external scripts, that is. In that case, add "bind core engine classes to Squirrel" to the list.
But that's turning out to be a case of implementing bindings as I need them.

Without giving away anything... I've already come up with around 50% of the game. It includes one core gimmick, utilizes a style of gameplay similar to one of my favourite games, and will have simple art.

Not necessarily "NES" art, just "simple" art. Custom palettes, limitations be damned when I feel like it.

Otherwise... I have a 'story' mapped out. Protagonist, antagonist and support characters.
Also started sketching a few ideas for enemies, bosses and items on paper.

Can't wait for the start of the comp :P

Other stuff

I've been playing a ton of Cataclysm: Dark Days Ahead recently. It's a post-apocalyptic roguelike with nearly as much depth as Dwarf Fortress.

That is a gas station. Those blue lines on the ground are gasoline I poured out.

I have a lighter.

Things ended spectacularly, completely disregarding the fact that I died. The fireball was glorious though. :3

Some of the more interesting features include:
> Rigging up a shopping cart with an engine and watching it go.
> Crafting tables/chairs out of stuff you just broke.
> Opening the back of a truck wondering what that smashing noise was and getting
swarmed by zombies.
> Molotov Cocktails
> Crashing a big truck into a gas station.
> Finding your past bodies littered around said gas station.
> Building Rube Goldberg contraptions out of scrap.

Well, that's enough out of me.
I'll leave you with this:

Scripting Languages
Posted on September 05, 2014 at 07:28

I decided last night to start writing a few more progress blogs for my more 'mundane' projects.
So here's a blog. It's probably dry, but you can always drink a can of soda while reading it :P

My Engine
Last month marked the 2 year anniversary of Exile, if you can call it that.
That also means it's been a whole 2 years I've spent working on the engine, making it the longest running project I've ever stuck to.

Recently, I started another engine for 2D games that had a few nifty features... but I decided that having two engines wasn't good for progress, so I pulled the new features from the new engine and replaced some of the old modules in Exile Engine (The Logger, Config handler, Object handler and Asset Loader).

I'll probably write a separate blog entry or two about some of these features, and how I implemented them... but today I'm writing about my choice of scripting language.

Exile was coded from scratch in C++. The original code was around 14000 lines of code, and was a tangled mixture of framework and game logic.
One of my major goals over time has been to separate the "Game" from the "Engine" in a comfortable way.

Recently, I added in Lua support to the engine, binding a lot of commonly used functionality, and managed to dynamically detect and load scripted objects at runtime (So new scripted entities could be created on the fly).
But I started running into a few major problems.

Firstly, I assigned each script a separate VM. For obvious reasons, this made communications between objects a nightmare.
I changed this to a single VM multi script system, where all scripts were loaded on startup, and a convention-based entry point was called.

Then I ran into my second problem. Lua is messy. That is, it gets messy when you start to code anything as complex as a game.
The syntax requires a lot of keywords I feel are unnecessary (do, then, end, for instance, could be replaced by { and }, and the language would feel a lot cleaner).

And the final problem was the way the engine used scripted entities. The ScriptedEntity type, a child of GameEntity, loads a script and calls the entry point (Based on the filename. So GameOverScreen.lua would have an entry point of GameOverScreenMain).
For various reasons, this ended up being a pretty much big mess. The entire engine is class based, but Lua doesn't have a good class system (Tables are messy when you try to make them 'work' in lieu of a good class type).

So to cut a long story short, I ditched Lua.

There were a few alternatives I was aware of, those being Python, AngelScript and JavaScript.
Through a process of trying things out, I discarded all three.
Python is too bloated, and binding classes is a pain in the ass.
AngelScript is too unstable, and has slowdown issues.
JavaScript is just one big 'no' for me, mostly because of the syntax. I know it's C-like, but some of the quirks put me off.

So I went and fished around a bit more, and found out about Squirrel, a scripting language that Valve has been using recently (Most notable in L4D2 and Portal 2, for scripted scenes apparently).

Note (Show)

And it is beautiful.

Essentially, Squirrel is similar to Lua on its lowest level. Tables are the de-facto data type, but there exist mechanisms to define classes easily.
Instead of keyword based blocks, the familiar { and } are used instead.

And best of all, it's tiny. The source for the library is under 300KB of code, and is easy to compile.

And finally, it's fast. LuaJIT can beat it in terms of raw speed, but I'll take the better syntax over a few micro-seconds of speed gained :P

Persistent Problems
I got Squirrel integrated to my engine pretty quickly. I found a decent binding library called Sqrat that allowed me to quickly bind engine classes as actual class types, and static functions to the VM, and generally speaking... all was well.

Until I started trying to get things to work together.
Squirrel lacks script-side import/include functionality. Generally, one could just load all scripts in a directory on load and their contents would be added to the scope.
But I want things a bit clearer, and better defined.

For instance, one of the things I want to do is have certain engine modules call specific 'game' modules. At the moment my main modules are:
> Main Menu
> Editor
> Game

So ideally, there would be a separate entry script for each, with a convention-based entry point (S_main in my engine).

Squirrel has a 'dofile()' function that basically loads and evaluates a script file during runtime, from within a script... but I couldn't get it to work.
This might have something to do with the fact that I'm pre-compiling all scripts before running the game.
Sqrat also has an 'import' library that only seems to work on scripts that haven't been compiled yet.

And I kinda want my scripts to be compiled. I don't want people randomly screwing around with some of my core game logic :P

The solution
I spent most of last night thinking "Maybe I should write a tool that lumps all the scripts together when building and compiles that".

Then at some point while considering that, I remembered that I already had a tool available to do that for me: The C Pre-processor.

In my makefiles for the scripts, I invoke GCC with the -E and -x c switches, and output an intermediate script file that I then compile into the final module.
And all I need to do in my scripts is use the familiar #include directive.

Well, I'm done. Sorry if the blog rambles on a bit too much :P

Ludum Dare 30 - Post-Mortem
Posted on August 28, 2014 at 19:02

I actually pulled off a game for Ludum Dare #30.
The theme was Connected Worlds, and as usual, I set out to make a platformer with the usual art and music styles.

Boy did I end up making something completely different...

I present to you... Shattered Horizon

Give it a play if you haven't yet! I'd appreciate it!

Or, you know, read the post-mortem if you have played it. I'll be going over what I remember of my thought processes during the comp.

I streamed (And saved to YT) a few ridiculously long videos of the development process. Two 5 hour vids and a 1 hour vid, I think. Take a look here if you're bored and have no drying paint to watch instead:
Part 1-1
Part 1-2
Part 1-3
Part 2
Part 3-1
Part 3-2

I'm not talking over these videos. I was too focused to bother :P
I did, however, start capturing my desktop sound once I started adding sounds and music to the game. So if you want to hear that, take a look at Part 3-2.

Post Mortem

Before the comp started, I had brashly decided to create my game in C++.
Because I'm a masochist, apparently.
Then things happened: I had to work on Saturday for most of the day, and ended up losing around 20 hours (Because of other things, family related).

So I started out at around... I have no idea when... on Saturday evening.
For some reason, I blanked out and started making my game in C++ from scratch. About three hours (And a working patial framework later), I remembered that I had uploaded an engine or two to Github...
I switched to my newer engine, IndieBoy.

It's important to note that I still had no idea for my game, other than "Platformer =DDDD" and not much else.

After another... four or five hours of screwing around with that, I realized that I was spending way too much time implementing new engine features and far too little on actually making a game. So I decided to drop my original plans and go with GM.

At this point, I actually started to think about game design.
Interestingly, Blackhole had hosted a copy-competition, 64Dare, that had a very similar theme to this Ludum Dare; my game for that, Alterality, got 'best overall'.
I decided to draw some elements from that game (The world swapping from a "light world" to a "dark world").

I also took a few ideas from a couple of story ideas I had a few months ago. The gist of these ideas being a planet that has a sun that periodically bombards the planet with "dark energy", a useful McGuffin that has created a dark side to the planet, inhabited by different people/creatures, but retaining the same physical objects for the most part.

And then I decided that making a platformer with these ideas would be a pain in the ass.

So I took a dip in the history pool and pulled out Gauntlet.
I've always wanted to make a game in this style, and decided to take a shot at it.

Some of the first things I did was establish a few basic core concepts:
> The game would be low-resolution to help with rapid art production
> The game would use a widescreen aspect ratio
> Gameplay is centered around the two worlds, Normal and Dark
> The Dark world is significantly more dangerous than the Normal world.
> There would be some basic 'survival' elements (Food and "Dark").
> Combat would be centered around guns.
> The Dark World would be entered after a specific time had passed.
> Food and Medicine would spawn at points on the map, and resupply after
a given time
> Enemies would continually spawn at the edges of the screen at specified ticks.
> Death is permanent

After a bit of fiddling around, I established a very low base resolution of 200x112, and eventually on a playing area of 112x112, with 88 pixels being reserved for the HUD. It made the screen a bit more 'cramped', in a sense, but also allowed me to get a decent HUD into the game without requiring a pause menu or other mechanism.

Around this time, I jumped on TeamSpeak with SpectreNectar, Pirate-Rob and Acid...
We were focusing so hard that we forgot that we were using TS, and it was deadly silent for the most part.

At this point, I started to work on basic gameplay. I had a simple prototype player sprite from the platformer idea that I was using as an HUD decoration, and used a simple circle in place of the player while I figured the basics out.
Then I decided to bite the bullet and face the task I looked forward to the least: Drawing the player sprite.
I'm not very good with top-down perspectives. I always want to add some more detail, the 'front' of the character... but I think I managed to pull off a character with a decent bit of depth, even though very little of it is shown at any given time.
The walking animation was both the easiest and hardest part of the player to figure out. When you basically have three squat circles next to each other, how do you make them appear to be attached to some legs that are hidden from view, and walking?

A couple of revisions later and I had a decent character, a simple map to walk around, and a basic movement engine.
I decided to go with GM's rotation in this case. It worked well enough for my purpose, though I usually avoid it. Then I made it 'smooth', so instead of snapping to a direction, you turn towards it at a fixed rate.

For a while I had a bug where, from certain starting positions, instead of turning in the direction the player wanted via the shortest route, the character would do a little reverse 'spin'. Made it look like he was dancing :P

Around this time, I decided that I needed a simple 6x6 bitmap font so I could print some info on the HUD. Just the characters A-Z would do for now... but I kinda forgot to keep it to that and drew a nearly fully-formed font-set, sans lowercase glyphs, in about 10 minutes. Worked better for me later, because I wanted to print the score too, and use some of the punctuation marks as bars/separators.

Now, my experience with short competitions... with any competitions, really... is that I leave my enemies and level design 'til last. I decided to break tradition with this one and swallow the bitter pill first.
I mapped out the entire game map in one sitting, and started drawing up enemies. In the end, I basically had two: Creatively named "Thing" and "Soldier". I made stronger re-coloured variants for the Dark World... Called "Dark Thing" and "Dark Soldier". Because that's as far as my mind was thinking at the time.

I toyed with the idea of quickly adding an A* pathfinder to the enemy AI (All base AI was handled by the parent object), but I decided against it, and instead implement a Fast Bogo Intelligence and focus on adding more features.

So now I had enemies that tracked and followed the player. I added in a spawner for them that would place them just beyond the edge of the screen if there was an opening, and moved onto the next 'big thing' that I usually left 'til last in my games:
The game over screen.

Not much to be said about that, but about an hour later I had managed to hammer out a Game Over screen, Title screen and intro cards.

Now, in a fit of reverse logic... I implemented the enemy's shots first, damage to the player (And death) after that... and only got around to adding a way for the player to fight back quite a bit later. :P
That's a bit of a turnaround from my common practice of forgetting to add a way for the player to lose the game in some of my games.

After I had that done, I added the switch to the Dark World. Actually, I had 'added' the Dark World a while back, but there were no triggers to enter it (I had a debug key to enter it. Which I forgot to remove from the game. Find it :P)

In Alterality, the world was 'switched' by switching rooms. That process was a pain in the neck, involving duplicating the first room I made, painting over the duplication with the 'alternate' tileset, and adding in extra hazards.
This time, I did something simple on game start:
> Create a temporary surface
> Draw tileset A to surface
> Save surface as background A
> Draw tileset B to surface
> Save surface to background B
> Assign backgrounds A or B to background C (The one defined in the GM editor and used in the room editor) during gameplay.
> Instant tileset switch.

And for world specific hazards/objects, I just made the player deactivate anything that was a descendant of 'obj_darkworld' if the world.mode variable was set to "WORLD_NORMAL".

After this, the only major things I added were the pickups and drops. There are three levels of each pickup: Small, Medium and Large.
Small food/med items drop with a small chance from enemies when you kill them, and restore a few points of food/hp.
Medium and Large items spawn in the world at predefined points, and respawn after a specified time (Somewhat buggy, I forgot to take a few things into account... but it works.)

Otherwise, most of the work from this point on was balancing: At first the food bar ran down too slowly. This was by design, since I originally envisioned a much slower paced game. A survival/roguelike/action hybrid of sorts, in which you would gather supplies and materials, etc, etc.
Obviously ditched most of those ideas very quickly. It was a Ludum Dare, after all :P

So I spent around an hour tweaking the Stamina, Hunger and Dark ticks. Made them a bit faster, tweaked enemy speed/damage/hp, tweaked player hp and attack, food restoration, etc.

Making this game was a lot of fun; I'm still working on it, and plan to release a polished "2.0" version at some point next year. Hopefully, by then, I'll have added in the new features I want (And features other people want):
> Huge maps (With a map system, so you know where you are)
> Randomly generated wilderness and cities
> WASD controls, with the mouse being used for interaction
> Refined survival elements, including the ability to barricade yourself in a ruined building in order to survive.
> Higher native resolution, with a more polished interface.
> 3D or pseudo-3D (Think of the original GTA).
> Boss battles!
> More enemy types, AI types... and proper pathfinding.
> Weapons! Items! Loot!
> Local multiplayer. The idea of a co-op Roguelike style game is appealing to me. And depending on how I code the base system, it might be possible to make it playable over the net too :P
> Rebase to C++, like it was meant to be. I already have the groundwork done for this game in my C++ engine, and am busy working on this already.

Ambitious, perhaps. But I'm finding that being forced to spend more time away from my computer (At work) tends to motivate me to work on things a bit more. So we'll see what happens.

I also plan on releasing a simple "1.1" release that'll fix a few of the nastier bugs (one of them being that food can run negative, and be extremely hard to get back into the green again), and a few new weapons.

Well, that's that. I'm off to go do something completely unrelated to work, programming or game design in general. I can't even remember the last time I've relaxed and played through a game. :<

NES Adventures - Part 1
Posted on August 16, 2014 at 14:47

I've been dreaming of assembly for the last two nights...

In his blog, Cyrus non-seriously challenged me to create a raycaster for the NES.

I'm not 100% sure whether I'll be able to pull that off or not, but I did start tinkering with some of the tools again, and decided to challenge myself incrementally. There's still a lot I have to learn about the NES hardware, and the tricks I can pull off with it.

So what I'm going to do is post blogs like this each time I complete a challenge I've set. The first one was to create a "text writer", something like the printf() function, for the NES.

I'm using pure assembly code, and a simple bitmap font. Strings are written to the nametable at runtime (A considerable amount of my time was spent last night trying to safely modify the nametables without glitching).
The result is this:

It's also scrolling, but you can't see that.
If you have an NES emulator, you can take a look at the ROM:

And here's the assembly listing for those of you who can read it :P
Warning: Spaghetti assembly code (Show)

There are a couple of problems with this code that I'm already aware of. Firstly, the nametable modification is inefficient. I only need to write to the nametable once, and leave it until I need to change it again.
At the moment, I'm doing it every frame.

The write_nt_str macro doesn't work, because I can't figure out how to pass a label's address to a macro with this damned assembler (I've nearly convinced myself to write my own assembler for 6502 code).

There are a bunch of inefficient comparisons/branches. I remembered afterwards that the lda/ldx/ldy ops also affect the C/Z flags, so...
Code: asm

;; I should do this
    lda $<somelocation>
   bne a_label

;; Instead of
  lda $<somelocation>
  cmp #$00
  bne a_label

Also, the scrolling is somewhat jerky when it hits the top of the screen. I'm derping somewhere in my checks, but I'll fix that next time I use scrolling.

Next up, I'm going to try do something a bit more complicated.

Coming up with blog titles is a pain...
Posted on August 06, 2014 at 06:31

So I'm going to start using The Video Game Name Generator to come up with them.

So this blog is now called

Bling Bling Dragon Choreographer


Anyway, I took a trip recently to the city of Cape Town. Was a rainy weekend, but I had a good time. And of course I had to visit the game shops and bankrupt myself.
Because that's how I do things.

I managed to get hold of Street Fighter IV, Bionic Commando and Red Faction 2 as part of a "3 games for R129" bargain (That's about $10). Was thinking of getting Dark Souls 2, but the retail price was far higher than Steam's price, so I decided to hold off on it for a while longer.

And then, while wondering around aimlessly in the local mall, I went into an electronics and audio shop for the fun of it. And I found something I had been looking for: An R4 clone.
An R4 is a flashcard system for the Nintendo DS series (You can use the DS ones on a 3DS too, to play NDS games and run homebrew roms).
And these guys were selling one of the units I was thinking of ordering from a local importer for about $30 less than the importer was selling it for.
So of course I snapped it up. And now I have what amounts to most of the good NES games on my DS, a bunch of homebrew apps, a DOS emulator, an SNES emulator that works really well (Can play Megaman X1, Super Mario All Stars + Mario World, FFIV, but not games like MMX2, X3, etc. Emulator isn't fully complete/compatible... I might just have to write my own :P)

But the real reason I got an R4 was so I could do silly things like port some of my games to it. For no real reason other than that it's something I've wanted to do for a while: Make something I can run on actual hardware.

And if I make something good enough, I can always pull a Battle Kid and make back what I spent on the unit :P

Other developments
My GBJam game is coming along... slowly. I've done more engine work than any game-related work, but that's fine by me. I'm actually looking forward more to the 7DFPS jam coming up directly after GBJam.

No, I'm not going to try make an FPS for the DS in seven days... ... Oh damn it all. I just thought of what Exile would look like on the DS...
Maybe if I can learn DevKitPro's setup and the basics of libnds in time, I'll take a crack at it. :P
I can implement a software renderer pretty quickly if I have access to a good framebuffer. Give me a way of drawing pixels quickly and I'll pull it off.

Anyway, I was streaming development of my engine for a while on Saturday. You can take a look at the archive here if you want:

Comment about how screwed up/odd my programming style is below.
And yes, I'm fully aware that I'm still using OpenGL 1.2 functionality. I'm just keeping things simple for now; the rendering code is pretty much plug-in/out as far as I'm concerned; a black box from an outside perspective. So switching it over to a shader based system should be a piece of cake.

Well, that's enough from me. Go blog some more guys, you're being boring. =3

Prev Page | Next Page

Recent Activity
Active Users (0)