hexagonal development Inc.

12000 lines of bad code running in loose formation.

[hexagondev]

look at this SUPER NICE text rendering

[hexagondev]

placeholder doodle.

[hexagondev]

By laziness, of course, I mean bugger all.

I’m in a bit of a slump right now. Once I've got some pesky job stuff out the way i’ll try and get more work done on hexstrat.

Or something else.

[hexagondev]

Just recovered my password, your regularly scheduled laziness will proceed as normal.

[hexagondev]

I joined a game jam. The theme is “Cold War” so naturally I’m making it about genocidal penguins.

[hexagondev]

Tips for Atari VCS/2600 gamedev:

Different emulators handle overscan differently. Z26 draws the VBLANK and overscan alongside everything inbetween, while Stella does it “correctly”, cropping the image to something closer to what would show on a 70′s TV set. (See picture)

Even if emulator filters aren’t your thing, quite a few games rely on phospor persistence to draw some special effects (Or even draw properly at all; like the Ghosts in Pacman/Ms. Pacman), so turn it on.

Batari basic, while a good idea in theory, is pretty rubbish in practice because of lack of cycle counting in code. CPU cycle counting is important!

There is no such thing as a pixel, only a TIA clock tick.

If you can’t compile on a 64bit machine, grab DASM from here, alongside vcs.h and macro.h which are pretty handy if you’re bad at remembering register addresses. Can’t remember where I picked it up but it works great

Compile with “dasm.exe SOURCE.asm -oNAME.bin -v4 >> out.txt” or something similar. This will pipe the debug log into a file so you can read it in something other than the command prompt.

You can’t draw more than 2 unique sprites on a line, but nothing is stopping you from fucking around with the NUSIZ0/NUSIZ1 registers to show more. (#011 is 3 sprites in a row) 

[hexagondev]

Slapping a quick demo together is easy, but if you want something to be maintainable long-term you’re gonna want a framework which means loads of debugging and work before you get even basic results. Shortcutting stuff to get results quicker just leads to cruft.

bloody cruft.

*cries into a pile of c# code*

[hexagondev]

Improved animation, the extra floors now grow out of the previous one rather than pop into existence. 

[hexagondev]

[hexagondev]

Another thing I should mention about this library is that it’s a ~spooky~ one and when a certain event is triggered it transforms sorta like this. For spook reasons.

[hexagondev]

I've been taking a brief detour from hexstrat to put together a short (like 10 minutes short) story based exploration game set in a library. I’m trying to set the plot up so it ties into an actual RPG I hope to make someday in the future.

Thing to note : Bookcase texture generator, guaranteed* to never create an identical shelf!

[hexagondev]

2 hours later, I've worked out how to give the invaders separate sprites.

[hexagondev]

Well, I managed to get DASM to cooperate (and found a Win32 binary!). Now I’m gonna make that space invaders game the world has always deserved....

wait..

Only 2 sprite registers?

uhh.

[hexagondev]

I just had some fun trying to set up a dev environment for making Atari 2600 games.

Did I say fun? I meant pain. 

Dead links, 16bit exe’s that don’t work without DOSbox, the one compiler I can find (DASM) being REALLY STUBBORN about input files and simply not doing anything most of the time.

at least the sample program compiles.

(full image)

[hexagondev]

bleh

[hexagondev]

One thing I like about gamemaker is that you can knock out ideas really really quickly. My eventual next project will probably be a racing game and I wanted to check if my idea for rendering roads was valid. 15 minutes later, Bam!

[hexagondev]

Added armys to the editor and did some behind the scenes tweaking to accommodate it. Buildings and capturables next!