Hexapelago (working title)

[cola5pandex]

Week One

Not a lot to show so far I'm afraid.

I have a routine that renders the hexagonal tile map but being trapped in the 80s I went and wrote that on BeebEm. I would like to make my code available for scrutiny (always room for improvement) but I'm not sure if it's fit for human consumption at this stage. So if anyone can advise on more suitable, modern assemblers I would very much appreciate it.

I also have a screenshot (because a picture paints a thousand words) but as far as I can tell I need to set up some kind of image hosting before I can post that here. I will try to sort that ASAP.

I basically just wanted to get a thread started and see if anyone is interested. I know this probably seems a bit mysterious right now so... Any questions, just fire away.

[Cybershark]

When creating a new message, scroll down to the Attachments tab, then simply add your image file. No need for external hosting

[cola5pandex]

When creating a new message, scroll down to the Attachments tab, then simply add your image file. No need for external hosting

Well they hid that quite well didn't they? Thanks for that.

And I just got back from setting it up on Google Photos (which I forgot I had).

Let's try again then...

There you go. Just worth mentioning that the map is completely random ATM. Hopefully it gives a rough picture of where I am going though.

[jubber]

Already looking promising, and visually distinctive compared to other beeb games. Mode 1 for the win.

My first assumption was a tactics or advance war style game, but it could just as easily be zelda-like exploration. What sort of game are you going for?

[Cybershark]

Already looking promising, and visually distinctive compared to other beeb games. Mode 1 for the win.

I assumed it was monochrome MODE 4. Gives a lot more memory to play with and, based on the look of that screenshot, no other colours are required

My first assumption was a tactics or advance war style game, but it could just as easily be zelda-like exploration. What sort of game are you going for?

Got me curious too. Are we talking turn based strategy, or something in real time? Your forum avatar - which I presume is related - looks like a Star Wars droid?
Great to see anyway, as new game dev seems to have dropped off a bit here

[sweh]

So if anyone can advise on more suitable, modern assemblers I would very much appreciate it.

"beebasm" is a very common tool used to assemble stuff these days. It's massively faster than native assembly, lets you use modern IDES, and can even build an SSD for loading into beebem.

[jubber]

I assumed it was monochrome MODE 4. Gives a lot more memory to play with and, based on the look of that screenshot, no other colours are required

I noticed that the cursor was white, otherwise I'd have guessed MODE 4 also.

[Cybershark]

I noticed that the cursor was white, otherwise I'd have guessed MODE 4 also.

I assumed that was why you'd drawn that conclusion and actually had to go check the native behaviour - as I was confused why the > prompt was green but the cursor line was white. It surprised me too, but I found that the cursor is exempt from colour changes and remains white.

[jubber]

Holy rudeword batman - I've never noticed this before! Of course, I'm getting on a bit - perhaps I knew this once, a long time ago.

How is the Beeb drawing the cursor? Separate chip, or some facet of the .. ah, the 6845 has a hardware cursor apparently. Nifty. Now I have some reading to do. Good catch Mr. Shark!

[sweh]

Holy rudeword batman - I've never noticed this before! Of course, I'm getting on a bit - perhaps I knew this once, a long time ago.

Of course most programs that change the colours also turn off the cursor so you don't see it!

[cola5pandex]

Guys... I will get back to you all in a while but let me just clear up this cursor thing for now (to save everyone trying to figure it it).

The cursor is done in a very similar way to a hardware sprite or mouse pointer. It does not exist in screen memory. It is added by the video processor as it goes along. Strictly speaking it's not white either. If you move it over green pixels it turns magenta (180 degrees opposite green on the colour wheel). I believe that's done by a quick XOR (or EOR if you prefer) to the underlying screen data (but not in the screen memory, only as that byte goes out to the display). The idea being that it is always visible with maximum contrast even against a white background.

Hope that makes sense. I'm rushing right now.

[cola5pandex]

Of course most programs that change the colours also turn off the cursor so you don't see it!

My program has ended and returned to BASIC (hence the prompt too), although I haven't turned the cursor off while it's running at this stage anyway.

[tricky]

Looks great, there is also syntax highliting for BBCBASIC and 6502 for VSCode, although I'm a VS user, so I wrote a colour highliting extension for that, but as with most of my stuff, it isn;t finished
I also keep seeing diagonal lines with different shaders of green, but as they move as I look at different parts of the image, I guessed that they weren't there
I also have to go and check my emulator now to see if I EOR &FF or more likely EOR with colour 0 when off and colour 7 when on!

PS You can also just drop the image on the page assuming you are on a PC, .PNG appreciated for beeb screen shots

[cola5pandex]

I also have to go and check my emulator now to see if I EOR &FF or more likely EOR with colour 0 when off and colour 7 when on!

I assume you're referring to the cursor here. No idea why you would need to do anything when it's off (other than output the screen memory as is). You would only need to reverse the XOR if the cursor was overwriting the screen. But it isn't, is it? The screen memory is unaffected. The reversibility of XOR is often quite important (because 180 + 180 takes you back to where you started) but I think in this instance it is purely about the contrast created by moving to the opposite side of the colour wheel. Maybe I'm missing something though.

I will get back to your other comments once the kids are asleep. I really appreciate all of it.

[tricky]

I was thinking that I might have had it EOR colour 0 when "black", but I just do ~= when on and nothing when off, so all good

[cola5pandex]

I was thinking that I might have had it EOR colour 0 when "black", but I just do ~= when on and nothing when off, so all good

OK. So here we are getting completely side-tracked and off topic (the cursor won't even be in my game) but I just can't help trying to get to the bottom of this. And now I'm completely baffled because as far as I'm aware ~= is just a comparison operator. So how on earth do we get from green to magenta, yellow to blue, etc with nothing but a comparison operator?

I also have a feeling that when you talk about your emulator you mean that you are the actual author of BeebEm. This is interesting because I almost forgot that we're not necessarily talking about what an actual Beeb does. It could be that your emulator isn't 100% faithful and an actual Beeb does things slightly differently. It's hard for me to say for sure because I haven't seen the real thing since the 80s. I do have some vague memories of coming across this back then but when I say vague I mean I could just as easily have dreamt it. Can you just clarify what you mean by "my emulator" and confirm how faithful this emulator actually is?

I think you may have said "all good" a bit too prematurely considering that you are probably the only one who knows what you are talking about.

[cola5pandex]

Already looking promising, and visually distinctive compared to other beeb games. Mode 1 for the win.

Thank you. I am aiming for something different, both visually and in terms of gameplay (I'll come back to that) so nice to hear that hasn't gone unnoticed. Mode 4 (see the other comments regarding the cursor).

My first assumption was a tactics or advance war style game, but it could just as easily be zelda-like exploration. What sort of game are you going for?

That is the question. So originally I was going for some kind of turn based tactics or strategy (some of my faves being XCom, Gears Tactics, Civilisation, etc.), although as a rule I do like to evolve software as I go along rather than rigidly sticking to a plan. And like you say... there are possibilities with this. I actually have a funny feeling that I might end up with more than one game based on the same basic hex grid setup.

But here's my question... What would people like? Market forces are a thing even when there's no money involved, because my ultimate goal is for people to have fun playing my game. My kids are already chipping in and anyone else who would like to contribute is also more than welcome (ideas, graphics, maps, etc). The only real limit is the amount of RAM available for the end credits.

[cola5pandex]

I assumed it was monochrome MODE 4. Gives a lot more memory to play with and, based on the look of that screenshot, no other colours are required

You are correct. 10k is a high price to pay for a couple of extra colours, especially when that's highly likely to increase the size of my tile / sprite sheets too. So Mode 4 it is. I think 1 bit pixel art is pretty cool anyway (if I can master it) and it's certainly extra retro, especially in green.

Got me curious too. Are we talking turn based strategy, or something in real time? Your forum avatar - which I presume is related - looks like a Star Wars droid?
Great to see anyway, as new game dev seems to have dropped off a bit here

See my previous reply regarding the gameplay. The avatar is related in the sense that I made it while I was playing with design ideas for the game. It did happen somewhat by accident though and I don't plan to put BB8 in the game. Uncle R2 maybe (you never know) but BB8 is a bit too modern day. I basically just like Star Wars and I used to program industrial machines (aka robots) so there he is (made by a company called Industrial Automaton in a galaxy far, far away and keeping a watchful eye on you lot ).

[jubber]

Well, we don't have a really good conversion of Crysis on the beeb

But if that's not your bag your grid immediately makes me think of some kind of turn based tactical shenanigans with bombs - so bomberman style area clearances while the computer uses asymmetrical baddies against you. You're trying to clear the grid of trees, moving one place at a time, except for hero units or when a pickup is used up. The enemy deploys pieces with movement restrictions, like chess pieces, and line of sight weapons. You can leave concealed bombs. Can you clear the map before losing all your units? Hmm. I almost want to write this now - but I have a newborn, so I may never get a chance to code again.

Or a dungeon crawler, where moving off the edge takes you to a new screen. You have to find the seven crystals of whatever, while carefully hoarding coins, defeating rpg enemies and slowly levelling up. 2 colours might make a varied RPG experience tricky, but at least you have the ram for it. Beeb rpgs were rare, and very thin in terms of variety of gameplay when they did show up.

Or a gentle farming game where you have to tend to a vast map full of niggling issues

Or the grid is a huge puzzle - much like Minesweeper but where you have to use clues to uncover treasure.

Hex grids are great. Think you can stuff Civ IV into 19.5K?

[tricky]

I used to like hex based tabletop miniatures and RPGs, diagonals being faster or convoluted always felt wrong.
I didn't write Beebem but have contributed a few bits.
I only recently started my emulator as I wanted one designed for debugging and exploring hardware which requires lots of new hardware debugging features and I wanted to understand every line of code to make adding them easier.
in C/C++, ~ is bitwize not.

Do you store your grid as a sheared grid or something else? I did that for a Chinese checkers game I wrote 30 years ago.

PS many people and all emulators have sideways ram now, so you could think bigger. I think it was fairly even 16K or 32K with a small % having more.

[cola5pandex]

"beebasm" is a very common tool used to assemble stuff these days. It's massively faster than native assembly, lets you use modern IDES, and can even build an SSD for loading into beebem.

I actually downloaded that the other day but I haven't tried it yet. I do have a couple of concerns though. BBC syntax and all that is great in a way but I'm not so sure about portability. It would be quite nice to get this game going on a C64 at some point so I'm thinking ahead. Thanks for the input though. I'm definitely not ruling it out just yet. Perhaps you can put my mind at rest as I assume you know more about this than I have managed to figure out so far.

[cola5pandex]

in C/C++, ~ is bitwize not.

I can't argue with that but ~= is a different story. I did assume that you would be using C++ but I've also seen ~= in other languages in place of != (presumably because that's more consistent than using ! for the comparison operator and ~ for the bitwise operator). Now if ~= was an assignment operator like += it would make more sense but I've never seen such a thing in my life (probably because it would surely be redundant). A = ~B (assign NOT B to A) is clearly a thing but the other way round just doesn't make sense to me. Maybe I'm missing something or maybe you just typed those operators back to front. You tell me.

Having said that, this all makes perfect sense now. I said "I believe" it uses XOR because I wasn't 100% sure and the fact that it actually uses NOT does make much more sense. It requires less gates for start. Not only that but it also explains something that has puzzled me in the past... The order of the Beeb's palette, which always seemed a bit random until now. ~0 = 7 (and vice versa), placing black opposite white. ~1 = 6, placing red opposite cyan (as per colour wheel), ~2 = 5, placing green opposite magenta (another 180) and ~3 = 4, placing yellow opposite blue (same thing again). Bingo Stingo. The order of the palette allows NOT to produce complements in both the numeric sense and the chromatic sense.

So basically... The vidproc works it's way through the screen memory converting logical colours (0-1 in this instance) to actual colours (0-7). Ordinarily it would then just output the pixels to the display as is but if its the row of eight that reside at the cursor position and the cursor is on then it inverts the colours first to produce the chromatic complements for each pixel. And this is how you can have a 1 bit screen buffer but still see four colours on screen without any changes to the logical palette (for which the timing could never be this precise anyway).

Hopefully we've put that one to bed now (other than the operator issue).

[SteveF]

I actually downloaded that the other day but I haven't tried it yet. I do have a couple of concerns though. BBC syntax and all that is great in a way but I'm not so sure about portability. It would be quite nice to get this game going on a C64 at some point so I'm thinking ahead. Thanks for the input though. I'm definitely not ruling it out just yet. Perhaps you can put my mind at rest as I assume you know more about this than I have managed to figure out so far.

Unless you get very fancy with beebasm-specific features, you would probably be able to port the source over to another assembler later on without too much pain.

And although the SSD output makes beebasm extremely convenient for BBC users, it can also save its output to regular files on the host machine, which you would then be able to package up as a C64 disc image using the relevant tools, so if you did create a C64 port you could still build it from beebasm source files.

That said, you can obviously use any "modern" 6502 assembler. acme seems quite popular (other assemblers are available!) and assembles to regular files on the host machine, which you could package up into an SSD from a build script using something like sweh's MMB_Utils.

The nice thing about beebasm is it's a kind of "one stop shop" for Beeb development. It can tokenise BASIC, which is handy if you want to write loaders or other non-performance critical code in BASIC, as well as produce an SSD with no extra effort. But once you have a build script set up, using a generic assembler like acme works just as well (and you can use beebasm just to tokenise BASIC, or use something like basictool). It's just setting up the build script and associated tools in the first place that is a bit of a faff if you don't use beebasm.

PS Very cool looking project, by the way!

[SteveF]

The order of the Beeb's palette, which always seemed a bit random until now. ~0 = 7 (and vice versa), placing black opposite white. ~1 = 6, placing red opposite cyan (as per colour wheel), ~2 = 5, placing green opposite magenta (another 180) and ~3 = 4, placing yellow opposite blue (same thing again). Bingo Stingo. The order of the palette allows NOT to produce complements in both the numeric sense and the chromatic sense.

This is an interesting observation which hadn't occurred to me before. I always interpreted the palette numbers as a 3-bit binary %bgr value in my head. Maybe this is saying exactly the same thing in a different way, but I think it's a neat observation even if that is true.

[tom_seddon]

I actually downloaded that the other day but I haven't tried it yet. I do have a couple of concerns though. BBC syntax and all that is great in a way but I'm not so sure about portability. It would be quite nice to get this game going on a C64 at some point so I'm thinking ahead. Thanks for the input though. I'm definitely not ruling it out just yet. Perhaps you can put my mind at rest as I assume you know more about this than I have managed to figure out so far.

The best 6502 assembler I've used is 64tass: https://tass64.sourceforge.net/ - really excellent, with loads of great features. I've also found the author very helpful when filing bug reports or feature suggestions.

It has no BBC Micro support whatsoever, though, so for Beeb stuff you're a bit on your own! For ROMs, its flat file output is fine; for files to go on disk (where load/exec address is relevant), I use Python scripts to convert the C64 PRG output files into something the BBC can use. See prg2bbc and ssd_create here: https://github.com/tom-seddon/beeb/tree/master/bin

--Tom

[cola5pandex]

Looks great, there is also syntax highliting for BBCBASIC and 6502 for VSCode, although I'm a VS user, so I wrote a colour highliting extension for that, but as with most of my stuff, it isn;t finished

Thanks. I did downloaded VSCode yesterday so glad to hear it being recommended by Acorn folks. It suggests I am on the right track. The last time I used any kind of IDE or code editor on a PC I was writing win32 apps. What's hot and what's not these days is a mystery to me. Hopefully I'll be up to speed before too long though. You guys are really helping with that. I appreciate it.

I also keep seeing diagonal lines with different shaders of green, but as they move as I look at different parts of the image, I guessed that they weren't there

I don't know what that's all about. Are you viewing at original size? I took the screenshot from a 640x512 window so each Beeb pixel is actually four screenshot pixels, which could possibly have strange effects when scaling.

[cola5pandex]

Well, we don't have a really good conversion of Crysis on the beeb

That's an FPS isn't it? It seems highly unlikely at the moment. I'm trying to avoid clones, I don't do FPS (with the odd WWII exception), and I don't think the Beeb does FPS either Never say never though, eh?

But if that's not your bag your grid immediately makes me think of some kind of turn based tactical shenanigans with bombs - so bomberman style area clearances while the computer uses asymmetrical baddies against you. You're trying to clear the grid of trees, moving one place at a time, except for hero units or when a pickup is used up. The enemy deploys pieces with movement restrictions, like chess pieces, and line of sight weapons. You can leave concealed bombs. Can you clear the map before losing all your units? Hmm. I almost want to write this now - but I have a newborn, so I may never get a chance to code again.

I can't fully picture this but it sounds interesting. Some of it is even similar to existing ideas that are floating about in my head. I was actually thinking about the possibility of clearing trees (for whatever purpose) and then having them grow back slowly over time. I've even done designs for different styles of tree at different stages of growth. It also ties in with another idea I have relating to my local (Black Country) history, the industrial revolution (rise of the machines) and deforestation, which then ties in to the history of computing and a company called Acorn. I've even designed an Acorn tree, aka an oak. And I really want to get something in there about that (computing history), even if it's just the odd easter egg and not really at the core of the gameplay. The chess bit too. The tactical missions in XCom and the like are really just chess with knobs on if you think about it.

They grow up (like trees). You will have free time again at some point. Take it from me. I've got six including my two step-daughters.

Or a dungeon crawler, where moving off the edge takes you to a new screen. You have to find the seven crystals of whatever, while carefully hoarding coins, defeating rpg enemies and slowly levelling up. 2 colours might make a varied RPG experience tricky, but at least you have the ram for it. Beeb rpgs were rare, and very thin in terms of variety of gameplay when they did show up.

Same again (great minds think alike). I have other ideas for moving between screens though. If we're going retro and digging into history then maybe we need a time machine. I've also thought about placing ports along the "coast" and, funnily enough, I've actually made seven temple looking tiles that might allow teleportation between the various realms of various gods. I think a full blown RPG might be a bit much but it could certainly have elements.

Or a gentle farming game where you have to tend to a vast map full of niggling issues

Or an arboretum rather than a farm. I've already got some growing trees.

Or the grid is a huge puzzle - much like Minesweeper but where you have to use clues to uncover treasure.

Another one I can't quite picture but it does sound interesting.

Hex grids are great. Think you can stuff Civ IV into 19.5K?

Hex grids are great. Civ IV is probably great (my Civ days were earlier instalments though). But that would be another clone.

No shortage of ideas anyway. Looks like I'm making five or six games then.

[cola5pandex]

I used to like hex based tabletop miniatures and RPGs, diagonals being faster or convoluted always felt wrong.

It was a board game called Escape From Colditz that started it for me. Hexagons are certainly closer to circles for range of movement purposes. They are also just a bit more interesting to look at than squares for me.

Do you store your grid as a sheared grid or something else? I did that for a Chinese checkers game I wrote 30 years ago.

At the moment the tile map is just a straight list starting from the top left tile, working right then down. 169 cells as opposed to 225 for a 15x15 sheared grid (because my map isn't rectangular). A sheared grid has advantages though. Like being able to keep track of position using cartesian coordinates. So I might switch yet.

PS many people and all emulators have sideways ram now, so you could think bigger. I think it was fairly even 16K or 32K with a small % having more.

Maybe a basic version and an enhanced version then. I do want to keep this Electron compatible if I can as well. My attachment to that machine is very strong due to the connection with other people I used to play with as a child. Namely my younger brother who is no longer with us. The first thing you will see when it loads up is "For Chris". Repton 2 was his game back then but we couldn't afford a Beeb.

[cola5pandex]

This is an interesting observation which hadn't occurred to me before. I always interpreted the palette numbers as a 3-bit binary %bgr value in my head. Maybe this is saying exactly the same thing in a different way, but I think it's a neat observation even if that is true.

The plot thickens. I never spotted that BGR pattern before but you are absolutely right. And it wouldn't even work the other way around (%RGB), suggesting that someone put a fair bit of thought into it. This scheme allows 3 bit RGB (just in reverse bit order, which makes no odds) and it allows a few NOT gates to flip the colour to it's chromatic complement without even blinking (let alone breaking a sweat). Both extremely useful techniques. Maybe it's just a coincidence that someone was able to exploit when it came to adding a hardware cursor to the design but I very much doubt it. Going for BGR, instead of the conventional RGB strikes me as totally intentional.

[cola5pandex]

I take that back Steve. This would work the other way around. I've just done the math on paper instead of in my head.

So maybe this is not entirely by design. More of a mathematical coincidence. But even still... It's a pretty clever exploitation of said coincidence because of the contrast it provides. And contrast is what colour vision is really all about. It helps things to stand out from one another. Really interesting stuff tbf.

Edit: further thoughts... Now I really think about it I realise this would work no matter what order the RGB bits are in. If one bit is set you get the additive primary. If you invert all three then you get the subtractive primary in between the other two bits (whatever additives they represent), meaning it will always be opposite the single additive that was set to begin with. And it obviously works the same in reverse if you start with two bits set. So NOT will always produce the chromatic complement (even if you use something really unconventional like %GRB).