Just one other thing… There’s someone nasty lurking at WOS.

Posted in Uncategorized on August 20, 2010 by zxdunny

And I just thought you should know.

Recently, there was a round of banning of unsavoury users that went on. Moderators were led to believe that one user had a vendetta against another, and said other produced IRC chat logs to “prove” it. Now, that other person is Nick Humphries, and he lurked (under an assumed name) in the #spin IRC channel, silently logging everything that was said – in particular the words of Andrew Owen, who was Nick’s intended victim on WOS. Nick didn’t contribute to any conversation in #spin, his sole intention was to gather ammunition for his vendetta.

Those of you that follow Comp.Sys.Sinclair may recall that Nick led a similar campaign of idiocy against Peter Thoma$, but Usenet being the beast that it is, he couldn’t get Peter banned – so he just attacked him at most opportunities. Google has the archives if you’re interested.

So anyway, Nick went off to WOS, and suggested that Andrew be banned. The upshot was that the moderators banned Andrew for 30 days, and Nick for 7 days. But that’s not all it seems – Nick had previously announced that he was taking a 7 day holiday from the boards. Make of that what you will, but it’s pretty plain that Nick manoeuvred the Mods into doing what he wanted.

Another (possibly intended) side effect was that other users got banned for being “puppet” accounts – one of which was my 16 year-old son.  Because his account uses the same IP address, and because he asked me what to write for some replies to folks on the board, he was banned also. That was quite scary for a young child of that age – he had no idea that people could be like that, but he knows now what sorts of people are on the moderation team at WOS.

So yes, there’s something nasty lurking at WOS. It’s called Nick Humphries, and he’s the sort of person that schemes in the background, silently lurking and gathering evidence to prove his twisted theories, and trying desperately to gain self-worth by making other people fight eachother at his whim. And it’s sad to see, it really is.

Here’s the reply I posted to WOS to Nick when he claimed he’d only discuss what happened in private:

Well, that didn’t last :-)

Posted in SpecOS on August 20, 2010 by zxdunny

Went back to Windows 7 because the linux desktop really isn’t ready for the mainstream. They can’t even get font rendering right, and the mish-mash of UI toolkits makes any apps you run look very non-standard.

I’ll keep the Slackware partition, but I’ll not be back in linux for anything other than compiling my apps.

Speaking of which, SpecOS is going well:

That last one is particularly pleasing, if not exactly fast. Still, I worked out that a real spectrum would need to be using a 9GHz CPU in order to execute the same program at the same speed! I’m assuming that means that sinclair BASIC isn’t very efficient :-)

No more Windows…

Posted in Linux on June 5, 2010 by zxdunny

A few folks may have noticed that development on Spin, SpecOS and BASin have somewhat stalled of late. There are several good reasons for this (the state of the Speccy community being one) but the main one is that I’ve pretty much abandoned Windows.

A while ago, I installed Win7 on my aging Samsung R60+ laptop. It runs like a dream, it really does. But it would appear that Microsoft and myself are drifting apart. Windows no longer makes things easy – in fact, at the moment I’ve got uTorrent running, downloading some software for my little project, and there’s no way in Windows to check what the download speed is. Normally, I’d just hover my little ol’ mouse pointer over the uTorrent system tray icon, and get the info. Now I need to find that icon before I can hover. I could easily tell Windows not to hide that icon, but the more icons get unhidden, the more space is taken up on that already-bloated taskbar.

And that’s just one example of how Windows is getting more unfriendly. More stable, yes – Win7 doesn’t crash for me, but that’s no longer enough. I’ve heard that other OS’s don’t crash either.

Another reason is that I have a Pandora on order. This is an open device, about the size of a Nintendo DS which runs linux (custom-built Amstrong distro), on an ARM cortex A8 processor. Not just the noddy “might be linux” that the GP2X and Wiz both run, but the real thing – XFCE desktop environment and all. It has a keyboard as well as the gaming controls (twin analogue nubs! Wheee!) and so I’ve decided that in order to get the best usage out of this thing, I’m gonna have to learn linux.

So here’s what I did, and how I did it.

First, I must say that I’m completely linux-unaware. Well, I know what it is, but I’ve never used it. I’m not afraid of a command-line; I was a very active Amiga hacker back in the day and I’ve heard that AmigaOS is very much like linux these days. I do still pratt around in WinUAE, but that’s not the same as it used to be. I know pretty much all there is to know about how Windows works – at least, I code for the Win32 API and have done for a long while. The filesystem is easy to understand, and I know what the Windows system files do and where they go. If Windows does go tits-up, I can fix it. Never had an instance where I couldn’t.

So…

Linux, eh? I asked a mate – “What do I need to get linux on this thing?”

Wish I’d never asked. There isn’t a “linux”. There’s “Distros” (or “Distributions”) and each one is a flavour of linux subtly different from the others. So a quick google later, and I chose my Distro. I wanted one that would teach me Linux, not just the basics, but the whole shebang. The Windows UI attempts to hide a lot of the functionality for you – a noble purpose, given that 80 year-old grannies use it – but that’s not what I want. I want something that when I say “I want to change the way I do such-and-such”, it says “Ok, have at it!”. There are distros that try to be Windows – Ubuntu seems to be one of them – and because of its graphical nature, I decided against it. I wanted to install, and then work my way up from the command line.

The one distro that stood out above the rest was Slackware. Why? Because I’d seen in the google searches that Slackware is hard. Not only that, but the overriding comment about Slackware was that “Slackware will teach you linux”. It’s phenomenally stable, the people who maintain it are fanatical about stability and reliability. Well, I’ll have me some of that, thanks very much! I don’t mind a learning curve, as this is purely about educating myself.

So, off I toddled to the Slackware site. It’s a reassuringly plain affair – no fancy graphics, just text and links. You can tell that these folks are serious about their image. I set about downloading the three CDRom ISOs for the 32bit x86 version. This will run on just about any PC you can imagine. My net connection is slow, so I just forgot about it for a few days.

About halfway through the second disk, I had an idea – what about 64bit? Am I running a 64bit CPU? Possibly, but I had no idea. Windows identifies my CPU as a “T2330″, and a quick google on that identifier brings up a wikipedia page – YES! It’s a dual core 64bit CPU. I aborted the CD downloads, and snagged the 64bit Slackware DVD ISO instead.

At this point, I’m getting quite excited about the idea of a new OS. And at the same time… What if things go wrong? A friend on IRC suggested I dual-boot. I’ve never done this before, but have heard about it.

Now, my PC setup is a 160GB HDD, with two partitions, both 65/70GB in size. I also have a 1TB external USB HDD, so I cleared out my D: drive (the second partition), backing up to that. There’s nothing on there but data, so no functionality was lost to the Windows system. Now what?

Googling “dual boot linux and windows” didn’t show much about Slackware, and the pages I did find were pretty confusing – using fdisk to set up a swap partition and create a linux partition is pretty much greek to me at this stage, so I conceded that I needed help.

I joined the LinuxQuestions forum. After searching around, I couldn’t really find the info I needed, so I posted – fully expecting the torrent of “use the search function, moron” responses I was inevitably going to get. In fact, I only got one relatively moronic reply – everyone else was helpful (and dare I say, enthusiastic?) in helping me. The one reply that was less than helpful contained the words “I answered this question two days ago” – but given that I didn’t know what to search for, his ever-so-helpful answer didn’t appear for me, and the pages he linked to were frankly bollocks to a guy who knows Windows but nothing else, and has never partitioned a hard drive before. I suspect some linux experts forget that everyone has to start somewhere – maybe they’re a little possessive of their hobby, and don’t like the idea of windows “n00bs” muscling in. I dunno.

Anyway.

I was advised to use the Windows disk management tool (search for it on the start menu, folks) to delete the D: partition, and then boot a linux live-DVD to do the partitioning. What, more downloading? You’re kidding, right? I only get 20KB/Sec! Or I could use fdisk. Or cfdisk, which is a “slightly more graphical version of fdisk“. Hmm.

I got a bit foolish then, and decided to do it without a live-DVD. What could possibly go wrong, right? Ha!

So, having deleted the D: partition (and changed my underwear afterwards) I popped my newly downloaded Slackware 13 64Bit DVD in the drive and rebooted.

Now, a lot of people who use Windows have a failing, and that failing is that they don’t read the screen. I’m no exception, and I had to concentrate hard to read what that DVD was telling me. It was, in fact, telling me to keep pressing RETURN at each prompt. Which got me to a command-line prompt. Oh dear. In the words of pretty much every text adventure I’ve ever played… “What now?”.

Well, I knew two commands (three, actually – fdisk, cfdisk and setup).

I typed “cfdisk” and looked in horror at the screen. It’s all text. If that’s a “more graphical version of fdisk”, I don’t want to see fdisk. But by carefully reading the screen, I created two new partitions – one, 5GB, set as a linux swap partition. The other, 70GB, as Linux. I looked around to make sure I had a supply of fresh underwear (yes, this is that scary) and wrote the partition info out to the boot block (or MBR).

Then I panicked, popped the DVD out of the drive and rebooted back into Windows 7.

Windows still boots fine, so I restarted again, with the DVD in the drive. I breezed through the prompts, and got back to the command line. This time, I was more confident. I almost nonchalantly typed the magic word, “Setup” and sat back.

Wow. It’s like the old 286s I used to code on back in the day. All DOS-style interfaces. Kind of cute, really. No-nonsense. No graphics. This installer just oozes confidence and stability. What could possibly go wrong, right?

The installer, when you read each part, is a breeze. Really. It’s almost impossible to fuck up – it finds (and formats) your swap partition, and your linux partition. I chose ext4 – because 4 is bigger than 3, so is obviously better. I noted that reiserfs was available, and I’d heard that one murders your wife, so chose to stay away from that one. Partitions formatted, I chose a keyboard layout, a font, and some other options I can’t quite remember (Oh yes, I chose KDE4 as my windowing desktop thing). Then I came to the end of the options, and (being the utter N00B that I am) told Slackware to just install everything.

It crashed.

Back to the start, I tried again – it must be a problem with the DVD or summats. Having crashed while installing “P” (and no, I have no idea wtf that is), I watched it crash while installing “A” the second time round. Oh dear.

Crash? No, the PC just shut itself off. I noticed that the underside of the laptop was very hot. The CPU had overheated. So I sat it on an icepack, and tried again!

About ten minutes later, I was asked how I wanted to boot this thing – it had noticed that I already have a windows install, and would I like to add it to the LILO (no, I have no idea what LILO is) loader? Well, fearing for my backup Win7 install, of course I would!

Here I should mention something very important.

If you let this LILO do its thing (whatever that is) in your MBR (boot block) then Windows might be well hosed. Enough to need a recovery disk. You can install to the linux partition though, to the “superblock” (you guessed it, I’m stumped as to what that is), and leave the MBR alone. If you do that, though, you’ll need to do what I did, and boot back into windows to use EasyBCD (a free download) to manage your Windows boot loader. It’s easy enough to do, and takes about 5 minutes.

So now I’m told to reboot. Which I do, and after a few moments of text flying up the screen (and with a couple of bluey-green tux penguins sitting at the top – more on that later), I’m prompted for a root password, which I give.

“Root” is “admin” in Windows. You’re probably an admin in Windows, ‘cos everyone is. You can’t get anything done without it. But Root isn’t quite like an Admin – there are differences, which I’ll get to in a later post.

So finally, after absolutely no hitches whatsoever (that is, none to do with installing Slackware), I’m sat at the command line, logged in. And absolutely lost. None of the commands (except DIR) that I know are working, and worse still, I’m quite scared that they’ll kill my install if I use them – they are probably different to the DOS that I know.

What now?

Fucked if I know. They don’t really provide a manual that I can get to on this machine. I tried “help” but that got me nowhere. It does give me a fortune cookie every time I log in, though.

Okay, so my previously elated mood has been… deflated, I suppose. I’m at sea, I’m up the creek without a paddle, I’m totally fucking lost. And it’s my fault. If I’d only gone with ubuntu, I’d be looking at a GUI right now. But I’m in Slackware, where idiots fear to tread, and I’m gonna have to deal with this.

Right! Reboot, back into Windows 7. Ah, sweet familiarity. No googling this time, I’ll talk to someone. A friend on IRC asks what’s wrong? I answer that I don’t think I’m ready for a command line yet. “No problem, just startx, and you’re done. You’ve installed X, yes?” “yes” “And you’ve got a desktop in? KDE or Gnome or somesuch?” “Yes”

“Just ‘startx’ then”.

“oh, ok.”

And back to Slackware I go.

I dutifully read the fortune cookie, then type in the magic word.

Oh my. The screen goes black, then a blue backround appears. It’s the right screen resolution, too, and even Windows 7 didn’t get that right. Then a taskbar, with what can only be described as a start menu! Joy!

It wasn’t all plain-sailing, of course, but for now I had a base that I recognised. I could tinker with settings and faff with the filesystem. I’m still root, so I need to be careful, but I’m happy. The command line can wait.I’ll deal with you later, my friend.

And KDE4 makes Aero look like shite. Seriously.

To be continued…

A year? Really? A year since I started this?

Posted in SpecOS with tags on December 12, 2009 by zxdunny

And about 9 months since my last post.

Ah well. Ok, BASin and ZXSpin are progressing well. Well, BASin is. ZXSpin is gradually being rewritten since Marko buggered off and left me to it. He’s taken the hump, cos he doesn’t seem to understand why his leaving the team upsets me. Ah well. He’s even gone so far as to hint that I might remove the assembler (and indeed, I suspect he probably would like to see all his code removed) but that’s not gonna happen this side of a court order :-)

The changes that I’ve implemented since all this seem to be going down well. The new scalers (both hardcoded and RPI) are well received, and the new aspect ratio code really does the business for people with widescreen monitors. I’m also quite chuffed at the new joystick code – supports all your buttons and your POV hat too!

Time for a break now.

So I need a new project :-)

A couple of years ago, I came up with a neat little idea. You see, I have this 486 laptop kicking around – and it wasn’t really doing anything useful. I mean, I had Win98 running on it, but that’s about it.

The one thing I don’t like about today’s computers is that you can’t just switch them on and bash out code. The Speccy let you do that (though only in BASIC) but there’s not even that on PCs nowadays. And they take too long to start.

So why not write me own? One that looks like a speccy, but is in fact a PC? With a nice 640x480x8bpp screen? And sprites? And stuff like that?

Well, that got shelved when I found that VGA wouldn’t give me what I wanted, and SVGA is a right arsehole of a system to code for. I’d got as far as a bootloader, 32bit PMode, a nice GDT/IDT setup… And then when I wanted to actually output something, it got suddenly very, very hard. Now, I’m not one to give up when things get rough. Not me. No, I go find someone else to do the hard part.

And I have :-)

A friend has popped up out of nowhere and said “you know that OS you were banging on about…”

So we shall see what happens. I’ll get updated details of how the OS will work, as soon as I have figured out what they are.

Ciao!

BASin news – bugs fixed, release 14d on the way

Posted in BASin on December 9, 2008 by zxdunny

Well, I’ve not been working on the 2D game engine for a while now – BASin is taking all my time. Back on WOS Forums, a guy called Jimmy reported some rather interesting bugs, which I suppose I might as well discuss here. 

The biggest problem is the Watches – a small part of BASin’s debugging suite. Basically, a Watch is a piece of information that is updated as a program runs. BASin supports a few types of these – you can watch variables, sysvars, memory addresses and the one that caused all the problems… The expression watch.

Expression watches are a small expression in Sinclair BASIC, such as “a+b*2″, which are passed to a dummy emulation to be evaluated as if the Spectrum itself were doing it. As such, they can take quite a while to get an answer from, but they’re generally pretty quick.

The problem was that Jimmy had written a small program which called USR 7962 – a valid expression which executed a small stub of code which upon return left the amount of used memory in BC, which was then passed back to BASIC. You can try it – type in PRINT 65536-USR 7962 to get a view of the number of available memory bytes. This worked fine in a BASIC program in BASin.

It didn’t work fine in an evaluated expression, such as a Watch. Finding out why was something of a pain!

In order to evaluate an expression, a copy of the current memory is made, and the expression POKEd into memory at E_LINE. The sysvar CH_ADD is set up to point to it, SP is set to 65534, with a value of $FFFF poked in, and then emulation is started from SCANNING in the ROM. The idea being that when SCANNING performs its final RET, it will loop back round to address 0, which is trapped and then the result extracted from memory and served up to the user. There are two passes – one with SYNTAX set in the FLAGS, to test for errors, and then one more pass to actually perform the evaluation.

The test that Jimmy had made utilised an unbalanced GOSUB system, such as:

10 GO SUB 20

20 GO TO 10

Which would, in theory (and indeed, in practice) allow the GO SUB stack to grow unchecked. The USR 7926 call would then report the dwindling amount of memory as the program runs. In the Watch, though, the USR 7962 result never changed. After much head-scratching, I decided that it must be because when the expression is POKEd in, STKEND isn’t updated properly. 

Nope.

As it turns out, SP is subtracted to find the end of usable memory. My routine sets SP to 65535… With that fixed, the result at least looks ok. 

Until someone else comes along, reporting that another expression fails. This is because it’s expecting there to be some 5-byte suffixes attached to numbers in the expression. No problem – I add those before the expression is tokenised, and away we go – all fixed!

Only now, USR 7962 doesn’t work anymore, and gives “illegal evaluation” and “Expression timed out” errors. 

After much more head scratching, it turns out that the USR function (and indeed, any function that calls FP-TO-BC) doesn’t want the 5-byte suffixes. So how do I get them all to work together? After a lot more head scratching, it turns out that the only time you should add the 5-bytes is after you’ve syntax checked… 

And now it all works fine. I’ve even managed to massively speed up evaluation, too! The new maintenance release of BASin will be along shortly – I’m adding some new stuff (like MIDI emulation for the PLAY command) and then I’ll release. All the bugs that have been reported so far are fixed.

 

Here’s a list of stuff I’ve fixed so far:

Fixed – The debugger’s flow control buttons (run, step etc) will also resume from a BASIC breakpoint now.

Fixed – The debugger’s program flow buttons would not properly reflect the state the emulation was in, and so wouldn’t single step or run from a breakpoint. (Jimmy)

Fixed – BASin can no longer be made to emulate a +2 by paging the editor ROM in inappropriately. (Jimmy)

Fixed – Some evaluations (like USR 7962, the “free RAM” routine), would time out or give “Illegal expression”. Lesson for today: “Don’t fuck with the stack pointer”. (Jimmy)

Fixed – keywords that follow other keywords (THEN GO TO etc) would not tokenise properly if there’s a space in the 2nd keyword – GO TO, GO SUB, DEF FN etc. (Ref)

Fixed – You can now save your SCREEN$ as .scr files from the paintbox. (ZXBruno)

Fixed – OVER 1 mode in the paintbox appeared twiced on the menu.(ZXBruno)

Fixed – Expressions can no longer OUT in the z80 core, so a lot of USR xxxxx expressions no longer screw with BASin. (Jimmy)

Fixed – Expression evaluations timeout a lot sooner now – typically after one frame of opcodes, rather than 5 seconds of emulation. This speeds up Watches quite dramatically.

Fixed – Expression evaluations execute very much faster now that redundant code has been removed.

Fixed – The Token Table tool was showing the wrong number for the keywords.

Fixed – The editor will no longer lock up if you insert either a SPECTRUM or PLAY token into a string.

Fixed – The Token Table now updates itself if your program changes from a 128k to a 48k compatible program, and vice-versa.

Fixed – BIN numbers were being truncated by the first digit. (AOwen)

Fixed – Binary notation numbers after a $C4 (BIN Token) inside a string were getting an extra (and unnecessary) 5 byte float value inserted. (AOwen)

Fixed – The token table returned the wrong token for keywords.

Fixed – Crash when deleting a watch whilst the program is running. (Jimmy)

Fixed – OPEN # and CLOSE # weren’t tokenised properly. (Jimmy)

Fixed – The parser no longer accepts CAT EXP as valid BASIC – BASin does not yet support +3 BASIC. (Jimmy)

Fixed – Getting command help on words like PRINT would return instead the help for INT. This also affected the right-click context menu for commands and variables with similar names. (Jimmy)

Fixed – The SPECTRUM command will terminate your program with report 0, rather than actually dropping to the 48k editor, thus rendering the BASin editor useless. (Jimmy)

Fixed – Clicking “Okay” in the Binary files handler when no binary is selected would cause a crash, even though this is something you should be able to do. (BadBeard)

 

Further progress

Posted in 2D Game Engine on November 12, 2008 by zxdunny

Not a lot to show this time, but rest assured that work is progressing. 

 

I’ve spent the previous few days implementing the level manager (and entertaining visitors, which explains the lack of updates) – this is the code that controls levels and their associated layers. It’s the thing that does the rendering of the level to the bitmap, and manages the scrolling. Callbacks are implemented both pre-and post-layer rendering, so you can processing the image of the game area as it’s built should you choose to do so.

The demo I posted in my first post was basically the layer manager and tile manager being used to mock up a level, and this code now wraps all that up into one unit. The aim here is to reproduce that demo using the level manager to make sure things all work as they should.

 

A level is basically a list of TLayerinfo types, which describe the layer to be drawn, and the offset x/y that it should be drawn at. Layers, as have been seen previously, do not have to be any set size (though being at least the size of the viewable area is good if they don’t wrap), and have a few values associated with them -

callbacks – these are fired off into user-code before and after the layer is rendered

Offsets – used to render the layer at the correct position

Scroll scalars – used to modify the offsets above by a set amount (float values) to perform scrolling. This will all be wrapped up by the LevelManager.ScrollLevel() procedure. 

Flags – this value is a 32bit DWord which hold boolean values on each bit for flags such as wrapping and collision/notifications.

I’m currently considering allowing a list of “states” to be specified for each level, where each layer’s position is stored – this would make it easier for the user to specify how a level will look when for example, a player enters that level at different points in the level. However, that’s for another day :)

Now I have to get the level editor done – a tool that allows you to visually set layers up and move them around relative to one-another. The asset loading and saving code is done for the level manager, so it should be a pretty easy job to get this done.

When all that is complete, I can start of Sprites and how they interact. This is gonna get pretty messy – as I mentioned previously, if  a sprite is moving at 3 pixels horizontally per frame (quite fast) and hits a wall, then the collision will fire only when the sprite is actually intersecting the object it has collided with. Obviously, if you just want the sprite to stop when it hits something, you don’t want it to appear to be buried inside whatever it hit! This is just one of the problems I can foresee, and will take some figuring out.

Suggestions on how to deal with this problem would be gratefully accepted – my current methods as planned will consume a not inconsiderable amount of CPU to implement, especially as there could be hundreds of sprites per frame with this checking enabled… Of course, not all sprites have to collide but in a bullet-hell type shmup, you’ll want a lot of collision to be checked. Or not, if you render the bullets first (with no collision) and then the player sprite(s) with collision. It’s this sort of thing I can’t accelerate with hardware support.

Ooh, the possibilities :)

Getting started

Posted in 2D Game Engine on October 24, 2008 by zxdunny

It’s about time I started blogging again.

There’s been a fair amount of interest in this – I’ve been making a 2D game engine in Borland Delphi, and I’ve had some people ask me to blog about the design and coding process. So that’s what I intend to do. The engine should be fairly capable, and is built around classes designed to handle one part of rendering a game. 

The design is simple – a 2D game is (usually) a room or level, which consists of tiles which make up the background and sprites which can collide with eachother and with the background. To this end, here’s the structure of the classes:

TGameEngine – the overall wrapper for the game. This contains:

TTileManager -

Manages lists of tiles. Each tileset is of a given size (say 16×16, or 32×32) and the tile manager is responsible for drawing each tile to a given DIB. Tiles have two masks – a collision mask (currently 1bpp) and an alpha mask for blending. The alpha mask is used when rendering to the DIB.

The tile manager also contains mechanisms for referring to tilesets by name rather than by index. More on how this is done later. You can add or remove tilesets using the methods provided. Each tile can have two callbacks associated with it for pre-and-post-processing – you can, for example, render the tile yourself and add say a blurring effect after it’s been rendered, or if you want to modify the DIB before it’s rendered then you are free to do so.

TLayerManager -

This class handles layers. Layers can be any size, and made of tiles from any tileset that share the same dimensions. Each cell in the layer can have a callback associated both pre-and-post render, as with tiles. The Manager is responsible for maintaining a list of layers that are used to create a TLevel. It is the part of the engine that renders a layer to a specified place in a DIB – or, rather it renders a layer to a DIB by centreing on a specified point in the layer. 

TLevelManager -

This manages a list of TLevel classes. The TLevel contains a list of layers used in a level, sprites utilised by that layer and certain flags – if the layer can be collided with, if the layer scrolls (and at what speed if so), various callbacks associated with pre-and-post layer rendering etc.

TSpriteManager -

This manages and draws sprites, maintaining a list of sprites and their masks and animations. Like tiles, sprites have both a collision mask and an alpha blending mask, used to render them. Unlike tiles, they can be any size and can appear on any layer. When drawn, they can trigger callbacks to notify the user that they have been drawn, and also (if set able to collide) when they intersect with certain tiles and other sprites. They can have any number of animations (all of which must be of the same size, like a TTileset).

 

That then, is as far as I have got so far. I’ve put a demo up – here’s a picture of it:

 

A demo of Layers being used for parallax scrolling, and also demoing the post-processing callbacks of TLevel.

A demo of Layers being used for parallax scrolling, and also demoing the post-processing callbacks of TLevel.

 

You can find the demo at http://paul.dunn.googlepages.com/TestGame2.rar

Yes, it’s a bit Ghosts’n’Goblins, and I’m probably the worst pixel artist in the world… But it does illustrate the points above. Use up/down/left/right to move around. There’s no sprites yet, just layers. As each layer is drawn, a post-processing blur and darken is added to the DIB used to draw the display. This isn’t the final engine method, as it relies on crappy windows timers. You can see where I’m heading here.

 

I hope to port this to fpc, so I can develop for the new Pandora console due out any time now. Let’s see how far I get :)

Next up though is getting the sprites in, and then collisions. It’s going to be interesting to do proper collision (a doddle to see if something has collided, but not so easy to determine if something will collide, and how much it can move before it does… when you have sprites flying around at more than one pixel per frame, it’s easy to get things stuck in the scenery, or worse – fly right through it!

All things I shall have to address in time. God help me.

Follow

Get every new post delivered to your Inbox.