SyntaxBomb - Indie Coders

General Category => Worklogs => Topic started by: Qube on January 26, 2019, 02:33:36 AM

Title: ZX Collection Vol #1
Post by: Qube on January 26, 2019, 02:33:36 AM
No title, no idea what game I'm going to do yet but thought I'd document my progress. Well I do have some game ideas but that's for later down the line ;D

I'll be using AGK for this comp entry and tonight I wanted to find out how AGK handles drawing lots of 2D sprites with mathematical positioning. Bit of a bizarre test you may be thinking but my initial goal is to do a ZX Spectrum game and build in colour clash and the odd screen flicker, so it'll require a lot of under the hood stuff. I don't know shaders so if I can figure out how to do it via coding alone it's going to be pretty busy behind the scenes, hence this weird test. I might have to ditch the colour clash idea but for now it's on the cards. It all depends on how performant it is but priority goes to the game itself first.

For a quick test I whipped up an over the top old school sinus scroller with a bit of funky extras. Turning off vsync it runs at 700+fps so I'm happy at this stage in that AGK can handle loads of 2D with math at the same time.

Exciting video below which uses an Amiga bitmap font ( so not even speccy related  :P - Oh, ignore the mouse, that's just there because it helps me be retro ;D ) :

Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Xerra on January 26, 2019, 09:26:37 AM
Reminds me of the C64 warez days and all those game intro's before decompressing :-)
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: STEVIE G on January 26, 2019, 10:11:49 AM
Is it not just a case of drawing everything in full white and having an colour overlay of 8x8pixel squares which are multiply blended?  The overlay can be dynamic to handle all your sprites.  Might only work for a black background right enough.
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on January 26, 2019, 11:22:01 AM
Is it not just a case of drawing everything in full white and having an colour overlay of 8x8pixel squares which are multiply blended?  The overlay can be dynamic to handle all your sprites.  Might only work for a black background right enough.
It’s easier to do if as you say the background is black but if not then it becomes a little more tricky. Probably just spend the weekend on this as the game is more important in the end :)
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on January 26, 2019, 11:57:13 PM
Today I fixed up my basic tile map editor to be all speccy. I can now select tiles and choose what colour I want them to be out of the glorious zx palette.

I then moved on to creating a sprite routine to deal with colour clash. 4 hours later it was up and running \o/ - I then looked at the result and went "Huh, what a twat!, that's doing colour clash in the extreme reverse".

So I present to you the completely wrong and highly dumb of me colour clash routine :)) - Waste of a few hours but made me giggle in the end :P - Will do it the proper way tomorrow *slap*

Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: iWasAdam on January 27, 2019, 08:01:45 AM
Can't see what's wrong there  ;D

Painting the pixels (with a color attribute) and the color overrides the color underneath it - it goes yellow - yep looks exactly right
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: blinkok on January 27, 2019, 09:42:56 AM
Is transparency counted as a colour?
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: STEVIE G on January 27, 2019, 10:53:48 AM
Can't see what's wrong there  ;D

Painting the pixels (with a color attribute) and the color overrides the color underneath it - it goes yellow - yep looks exactly right

My thoughts too.  What exactly is wrong?
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on January 27, 2019, 01:34:09 PM
( Jedi voice ) “This is not the effect you’re looking for”

I thought it was right too for a while. Then realised what should be happening is as the smiley face enters the couloured bars it begins to become the same colour, line by line, pixel by pixel.

If you watch some YouTube videos you’ll see what I’ve done is the reverse extreme version :P
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on January 27, 2019, 01:36:07 PM
Is transparency counted as a colour?
Yes, black ( transparency ) is a colour in computer land.
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: iWasAdam on January 27, 2019, 02:04:14 PM
so you were wanting to update the bit field without affecting the color attribute field ?
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on January 27, 2019, 05:54:34 PM
so you were wanting to update the bit field without affecting the color attribute field ?
When a sprite enters an 8x8 block which has a different colour it takes on that colour pixel by pixel as it goes in.
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on January 27, 2019, 10:27:08 PM
Although there are some Spectrum games that do colour clash as per the video above. I wanted to do the other method which turns out was harder to do but luckily managed to get it sorted. Faking this stuff is madness on modern tech :P

Colour clash test 2 - The correct way, go speccy go ;D

Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Xerra on January 28, 2019, 12:33:28 AM
Looking at this it's actually technically possible that the Vic could have had the same problem if it hadn't resorted to using poke commands for manipulating graphics. Out of the box it had no draw commands so you just poked a value into a screen memory location (22 * 23) and the 8 * 8 pixel character appeared there. To actually colour it you had to poke a value into another memory location which set the colour for that block on screen. To simulate movement of the character you would then poke it with 32 to put a blank space where it was and then poke it in the new location, so current location - 22, for example, to make it look like it had moved one space to the north.

One space would be 8 pixels due to the size of the char graphics. So, if you wanted to animate the movement by pixel (which was possible but very tricky) you had to use a bit operation of that byte to move the pixels left or right within each of the 8 lines of that char graphic. If you wanted to animate it going up and down then you'd had to look at the next or prev line of that char graphic and poke that number into the previous location. Then, every 8th time you did this you would just reset it back to the original image and move the block.

Very, very few games did this on the Vic because it would involve a fair bit of code which the memory just wasn't there for. But, assuming the Spectrum drew its graphics using internal routines so they could move a pixel at a time, then I'm guessing it's colour map worked the same way as the Vic and could only have one colour every 8 pixel square area.

It was probably a memory limitation that made them take a short cut with the Spectrums graphics operation if it was like this. The irony is that the Vic programmers just made everything work with poke and peek direct to memory because they didn't have time to create proper graphic commands. If they had then the computer probably would have got as much flack as the Spectrum for colour clashing because they'd tried to make it work better.
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: col on January 28, 2019, 05:41:35 AM
@Qube
Interesting competition :)

Both of your colour clash routines are correct, the clash was usually based on 'colour priority' of the sprite (in the attribute table) which would be programmer coded.

Quote
One space would be 8 pixels due to the size of the char graphics. So, if you wanted to animate the movement by pixel (which was possible but very tricky) you had to use a bit operation of that byte to move the pixels left or right within each of the 8 lines of that char graphic.
This was the same for the Speccy.

Quote
If you wanted to animate it going up and down then you'd had to look at the next or prev line of that char graphic and poke that number into the previous location. Then, every 8th time you did this you would just reset it back to the original image and move the block.
If only that were the case for the Speccy too, but it soooo wasn't that easy :))


The screen pixel and colour (attribute) data was made up of 6912 bytes of data starting at address 16384.
The pixel data was 6144 bytes folowed by 768 bytes of attribute data for a 256x192 pixel display.

Each attribute square was made of 8x8 pixels with just 2 of the 16 colours allowed in each attribute square - 1 byte per square - 32 squares by 24 squares - 768 bytes.
It would have been nice to have the pixel data for those squares layed out in sequentially in memory but it wasn't. It was made of 3 sections of horizontal blocks, with each block being pixel data for 32 square by 8 squares. So you had 8 blocks by 3 sections to give 24 blocks (192 pixels) high.

To make matters even worse the sequential memory access of the pixel data area would work as follows:

the first 32 bytes would be for line 1 of the 1st row of 8x8 pixels,
the next 32 bytes would be for line 1 of the 2nd row,
the next 32 for line 1 of row 3,
the next 32 for line 1 of row 4,
the next 32 for line 1 of row 5,
the next 32 for line 1 of row 6,
the next 32 for line 1 of row 7,
the next 32 for line 1 of row 8 of the first 3 horizontal section.

the next 32 for line 2 of the 1st row,
the next 32 for line 2 of the 2nd row,
the next 32 for line 2 of row 3,
the next 32 for line 2 of row 4,
the next 32 for line 2 of row 5,
the next 32 for line 2 of row 6,
the next 32 for line 2 of row 7,
the next 32 for line 2 of row 8 of the first 3 horizontal section.

At the end of the 32nd byte of row 8, the next byte would be line 1 of row 1 of section 2 and the previous pattern continued, until the end of section 2 then the same pattern occurred for section 3. Immediately after the pixel data memory follows the 768 bytes attribute table.

Ahh the good ole days :))

I'm sure that description was as confusing as hell itself so here's a loading screen on Youtube showing the data being loaded sequentially straight into the screen memory location.

Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on January 28, 2019, 06:46:33 PM
The vic-20 and spectrum didn't have any dedicated graphics chips unlike the C64. Mind you, could be worse and do a ZX-81 game :P

@col - Thankfully I'm not going into that much detail emulating the general look of a speccy game :o
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Xerra on January 28, 2019, 06:51:54 PM
Sure, but even with a computer that had no in-built hires graphics like the ZX81, you could do some great stuff.

The picture attached is a classic example. Because these machines were so limited, the people working on them had to find clever ways to make the most of what they did have.

At the end of its life-span I seem to remember that there were a couple of games that even managed to get custom defined characters on a ZX81. I was sure that was impossible.
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on February 01, 2019, 10:48:25 PM
Super early screen shot of a very small part of the planned game.

Look at those glorious hand crafted speccy graphics, I'm really pushing the boat out on this one :P. The cheesy CRT effect and colour clash will be optional via the main menu.

(https://www.syntaxbomb.com/images/ZXGame0001.gif)
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: blinkok on February 01, 2019, 11:20:07 PM
Superb!
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Steve Elliott on February 01, 2019, 11:24:24 PM
Looks good.
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: therevills on February 01, 2019, 11:41:30 PM
Looking good!
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on February 01, 2019, 11:53:09 PM
Yup, you can clearly see the PBR HDR render pipeline in action :P - Actually it's quite cute what you can fit into 256x192, you just have to think small and keep things basic.

Loads of graphics and things to do yet though as the above is just a tiny bit of what I have planned ;D
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: iWasAdam on February 02, 2019, 06:28:53 AM
oooh, very nice :)
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: GaborD on February 02, 2019, 06:42:32 AM
Looks great!
Nicely captures the feel of the good old times.
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Steve Elliott on February 04, 2019, 09:15:20 AM
That CRT effect, surely that's adding a colour the Speccy never had?
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on February 04, 2019, 10:26:35 AM
That CRT effect, surely that's adding a colour the Speccy never had?
Technically you could say it’s creating subtle shades of the colours but this is just an optional toggle effect in the menu which will be off by default. Colour clash will be on by default but with the option to turn it off too. So by default it’ll be as close visually to how a Speccy would look on a modern TFT :)
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on February 15, 2019, 04:39:57 AM
Hmm, so I've been working on a part of my game which is taking far longer than I anticipated. The player side took a couple of days more than I wanted but that side now works flawless thanks to a twist on a recursive fill routine ( keeping it vague ). However I've hit a stumbling block as one side requires pretty decent AI and I'm absolutely crap at AI coding beyond the very very basics.

Luckily it's the weekend so I've set myself a goal to either figure it out or ditch this segment if it's not working by Sunday night. I know what the AI should do but getting that into code is a total biatch :(. It's not my area but I like a challenge, even if I am falling asleep at nights wondering how to do it :P

Woot woot, that's the end of my worklog update ;D - Hopefully I'll be able to share things much quicker soon but for now I'm stubbornly refusing to give up and will figure it out, grr.
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Derron on February 15, 2019, 07:15:59 AM
Do you have trouble to do a certain aspect of the AI (simply said "run towards the player") or on the decision making of the AI?

If your entities in the game have abilities then it does not matter how the abilities are executed - via keyboard, gamepad - or AI.

Decision making is a bit harder - in TVTower the "default AI" (you can create your own - each AI takes a folder of Lua scripts) uses a "priority" system. Priorities are given for a multitude of tasks. In your game the task could be "guard the diamond" (lurk around the diamond item) or "chase the player". In an RPG game the tasks could be split into various things the NPC would do in its normal "life". Visit other NPCs, work on the farm, go to bed, ...
After a task is done the priorities are reevaluated and the best is the next (after a nap/sleep other things could be more important than working on the farm -> eg. going to toilet).
Also each task can adjust it priority each "tick" (or just on events...). This allows for "emergency priorities" ("the closer the player the more important 'guard the diamond' becomes").


If you explain a bit where you have issues with your AI (without going into the gameplay detail) the more likely we might be able to help out with ideas.


bye
Ron
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on February 15, 2019, 03:01:01 PM
Quote
Do you have trouble to do a certain aspect of the AI (simply said "run towards the player") or on the decision making of the AI?
It's not the "run towards a player" but more of the AI actually playing part of the game to a decent standard.

Quote
If you explain a bit where you have issues with your AI (without going into the gameplay detail) the more likely we might be able to help out with ideas.
Thanks but I'm stubborn and like to keep at it until I figure it out ;D
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Steve Elliott on February 15, 2019, 03:28:34 PM
Ooo AI.  I've just gone for a simple fun quirky game I liked on the old Speccy - and re-visited it; so no need for such coding.  Good luck with the problem, I'm sure you'll crack it.
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: MrmediamanX on February 15, 2019, 03:55:38 PM
AI? yikes ... my usual method is generally move,attack,stop,reset or rush,retreat,reset.
if it's anything beyond that ... i'm out. 
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on February 15, 2019, 04:00:37 PM
Ooo AI.  I've just gone for a simple fun quirky game I liked on the old Speccy - and re-visited it; so no need for such coding.  Good luck with the problem, I'm sure you'll crack it.
It's only for a small part of the game but I fancied having a crack at it ;D me and my stupid ideas :P. Think I'm on the right track now though as I appear to have had a bit of an early breakthrough thanks to shoving a load of debug info on screen.
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Steve Elliott on February 15, 2019, 04:37:14 PM
Quote
It's only for a small part of the game but I fancied having a crack at it ;D me and my stupid ideas :P.

That's partly what the competitions are about IMO - to learn new things.
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Xerra on February 15, 2019, 04:59:19 PM
I've got AI at the back of my head constantly, even though I'm a long way from putting other cars on the road in my game. I don't actually have a road for starters - the one I showed before was a tiled dump of the NES original game. In my head I've got rough ideas how the different cars should interact but I wouldn't start until collision detection was in so the road can be the extra weapon.

A state machine is going to probably be the way because they have to lose control for a while, rather than driving along doing whatever they should be doing, and also they need to move with the road so it appears they are accelerating to keep up with the player and do nasty things - unless they're not an enemy, of course.

All sorts of stuff to think about - not looking forward to it but i'm sure it will come together when it's time to start.
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: DaiHard on February 15, 2019, 10:59:46 PM
Sometimes the interesting thing with AI is working out how BADLY you want it to play! It's no fun competing against a perfect opponent -you are bound to lose. I think I first realised that with a moon lander program in the 80's: in the end I think I programmed it to land with something like a 10% safety margin, giving me JUST enough scope to beat it, if I played accurately...

:-)

D
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on February 16, 2019, 05:44:47 AM
I'm making some good progress and 60% of the time the AI is making good choices. This leads me to believe there are some tiny logic bugs in my game code which build up and sometimes result in a bigger error outcome. I think as things stand now I need to somehow visually output every choice made by the code so I can see where it's failing ( knowing my luck it's a stupid mistake )

OK... As a small part of the game I'm doing you can play a custom Speccy version of Puyo Puyo (https://www.youtube.com/watch?v=GHIQLqsWa54) and it's you vs the computer. It's probably not the easiest of AI's to code if you've never really done this sort of thing but I do love a challenge ;D

The basic idea of Puyo Puyo is to match four or more blobs of the same colour together and also make chains ( 4+ the same colour explode, board falls down and creates more 4+ blobs, etc etc ).

Currently the AI side looks for the best match across the columns ( including rotations of your two pieces ) + takes into account the effect of such action, i.e. the knock on effect of creating chains. If you watch the YouTube video you'll see that there are quite a few things for the AI to decide, eg, position, rotation and knock on effect. I also assume that greater AI's would use the upcoming colour combinations to work out the best scenario but all I'm after is a pretty decent CPU player and not some master wizard who never makes a mistake.

But as it's not always accurate there is definitely a bug or bugs somewhere in the logic. It's driving me absolutely nuts but I'm determined to sort it. I'm giving it the weekend to sort out but if by Sunday evening I've not figured out what's wrong then this side will be ditched, but I will come back to it after the comp as I refuse to fail :P

As said in a previous post, coding AI is not my thing but as it's a weak area of mine I thought I'd dive into a challenge ( as I like to do with the comps ) and it's been good to take a task and break it down into as simple as possible logic steps. Should've picked something like connect-4 / tic-tac-toe but that would have been a cop out.

I probably shouldn't be spending this amount of time on a small part of my game but I'm like a dog with a bone when I start things :P
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: 3DzForMe on February 16, 2019, 04:03:09 PM
@Qube
Quote
Although there are some Spectrum games that do colour clash as per the video above. I wanted to do the other method which turns out was harder to do but luckily managed to get it sorted. Faking this stuff is madness on modern tech :P

Colour clash test 2 - The correct way, go speccy go ;D
Wow, you're attention to detail with the colour clash is such great attention to detail, kudos.

@col...
Quote
Ahh the good ole days :))
I'm sure that description was as confusing as hell itself so here's a loading screen on Youtube showing the data being loaded sequentially straight into the screen memory location.
Its funny how the old grey matter works (or doesn't) I was genuinly thinking of invoking a screen loader of a similar nature to the Hobbit (but a lot faster... real time tape loading was defo for the eighties. Yep, blowing the 'authenticity' of the spectrum out of the window.) Maybe I could make up for it by prompting 'Select your tape players volume' inside a randomizer, so every time you try to load the game, you need a different number. Too much?

@Qube
Quote
I probably shouldn't be spending this amount of time on a small part of my game but I'm like a dog with a bone when I start things :P
I'm sure it comes from coding on the Speccy, gives you tendencies to go that extra mile ;)

Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on February 16, 2019, 07:35:21 PM
Quote
Wow, you're attention to detail with the colour clash is such great attention to detail, kudos.
Quote
I'm sure it comes from coding on the Speccy, gives you tendencies to go that extra mile ;)
I like to add new challenges when doing a comp entry to push myself to do new things ;D
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Derron on February 16, 2019, 07:41:33 PM
Regarding that bug and how to tackle it:
- instead of "random" use a mersenne twister pseudo random generator for everyting "not an effect" - so which blob colors are selected for new "blobs", for moves of the AI.
- let both players be played by the AI
- on game start set a fixed "seed"

That way you can play the same game over and over and see what happens if you change something (from that moment on the game might differ). This works as with mersenne PRNG and a fixed seed the random numbers are known in advance - and will always be the same on each restart. So if everything is based on this random numbers it will "play the same game". Nice to checkout stuff.


bye
Ron
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on February 16, 2019, 09:01:17 PM
Regarding that bug and how to tackle it:
- instead of "random" use a mersenne twister pseudo random generator for everyting "not an effect" - so which blob colors are selected for new "blobs", for moves of the AI.
- let both players be played by the AI
- on game start set a fixed "seed"

That way you can play the same game over and over and see what happens if you change something (from that moment on the game might differ). This works as with mersenne PRNG and a fixed seed the random numbers are known in advance - and will always be the same on each restart. So if everything is based on this random numbers it will "play the same game". Nice to checkout stuff.
Yeah, I just went for the easy route of putting numbers into an array so the game always plays the same and makes the same mistakes / errors so I can pin down the issue and know when it's fixed :)
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on February 17, 2019, 04:54:11 PM
Woohoo, got the AI to work \o/ - Plays a pretty decent game so that's me done on that side ;D

(http://www.syntaxbomb.com/images/itsworking.gif)
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Rick Nasher on February 18, 2019, 03:07:07 PM
Good to hear, but don't get ahead of your powers for you might turn into Dark Helmet.   ;)
(https://i.gifer.com/JNC.gif)
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: chessish on February 18, 2019, 03:11:48 PM
Looks good!
keep up the good work
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: therevills on February 22, 2019, 11:46:24 PM
Woohoo, got the AI to work \o/ - Plays a pretty decent game so that's me done on that side ;D

Screenshot or it didnt happen  :P
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on February 23, 2019, 04:47:01 AM
Screenshot or it didnt happen  :P
Lol a screen shot won't show the AI in action :P - Also my Speccy version-ish of Puyo-Puyo won't win any graphical awards as I'm aiming to keep all the graphics very basic on purpose. As it's just a small part of the overall game planned I don't think it'll be worth posting any screen shots of it as it's so basic looking compared to the other entrants screen shots and I don't want to give a false impression of the overall game ;D
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: 3DzForMe on February 23, 2019, 05:23:46 AM
Quote
I like to add new challenges when doing a comp entry to push myself to do new things ;D

Yeah, I'm a bugger for doing that myself, I think... Hmmm, I wonder if I could work some of this or that in as well... you usually can but in my case make my generic room handler do simple things like letting you turn a light on gets a bit head achey.

I've got all my rooms with responses to what you can do in them in a multi-dimensional array, arrays are great ;D
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on February 25, 2019, 07:15:16 AM
No screen shots or videos to post yet ( soon ). But tonight I revisited my colour clash code as it was performing slow. After a lightbulb moment I managed to lob off 300+FPS on that routine alone \o/

I also finished off the movement, climbing, jumping and falling for this particular part of my game. As I’m dealing with such a small resolution I had to add in coordinate reset code as delta time movement isn’t the best when dealing with pixel perfect constraints.

Also been creating some ZX 128-ish music which has been a whole heap of a challenge. I’m sure I’ll finish my game in time, I just need to learn the art of not sleeping or doing real life work stuff ;D
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: MrmediamanX on February 25, 2019, 07:48:57 PM
Also been creating some ZX 128-ish music which has been a whole heap of a challenge. I’m sure I’ll finish my game in time, I just need to learn the art of not sleeping or doing real life work stuff ;D

dooood ... i'm here just waiting till drop time. ;D
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on February 26, 2019, 03:29:50 AM
Quote
dooood ... i'm here just waiting till drop time. ;D
Mine won't be dropping until the last minute at this rate :o - Micro steps is all I'm managing at the moment :(

But today I did get around to heavily improving some code I did on a previous comp to fit more into my slow improving framework. Look at this lovely new command :

Code: [Select]
CreateEnemy( 1, 8, 16, 0.50, 9, 3, "R9R9L9L9" )
What that does is create an "enemy" at x / y coordinates, speed of movement, frames of animation, animation speed, animation movement string

The animation movement string is a simple L R U D ( left, right, up and down ) and the next value is how many tile map pieces it moves by. As it only takes one parameter for movement you do need to do something like R9R9 to move right 18 tile map pieces, but it keeps the code all streamlined.

Then in my main loop I have another command called HandleEnemies() which does all the magic of movement and animation on my tile map code. Makes it super easy to created animated moving enemies on a set repeated path. I'll be improving the animation string functions overtime but for now it does the job.

Well, wasn't that exciting to read? :P

Keeping with the boring stuff, here's my favourite created function *ever* :

Code: [Select]
SpriteZX( fImage, fXPos, fYPos, fScale, fAngle, fColour )
Draws a sprite from the ZX Spectrums palette of 16 colours but also handles colour clash between other sprites and the tile map. Super awesome! ;D

Anyway... Super exciting video's will be arriving soon soon :))
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: MrmediamanX on February 26, 2019, 04:01:53 AM
Nice ... I should throw up my basic blitz3d zxspeccy test somewhere.
its just a base test with no collision but its a thing guess. :D
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Xerra on February 26, 2019, 07:11:02 AM
It's the simplest functions that you end up using the most. This is the one I use more than anything else in my base project file for new games:

scrTextInit(c64Yellow,fntC64,fa_middle,fa_middle);


and the script it's calling:

/// @desc scrSetText(colour,font,halign,valign)
// @argument0 colour
// @argument1 font
// @argument2 halign

// @argument3 valign

// (C) Tony Brice - 10/03/2018

// Allows one line setup of major text drawing vars.

draw_set_colour(argument0);
draw_set_font(argument1);
draw_set_halign(argument2);
draw_set_valign(argument3);


Literally just sets the colour, font with the horizontal and vertical align for the next text draw command and I couldn't live without it /nerd
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Steve Elliott on February 26, 2019, 11:30:19 AM
Quote
Look at this lovely new command :

Code: [Select]
CreateEnemy( 1, 8, 16, 0.50, 9, 3, "R9R9L9L9" )

What that does is create an "enemy" at x / y coordinates, speed of movement, frames of animation, animation speed, animation movement string

Cool, a movement and animation script.
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: iWasAdam on February 26, 2019, 01:43:29 PM
I'm with Steve, animation and Movement script - well cool :)
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on March 04, 2019, 02:08:10 AM
Quick video showing a couple of levels of part of my comp entry. As you can see I've gone all out with the AAA artwork \o/. No music or sound is in this part yet and I've still loooooads to do.

Just in case you are wondering "Is that it???", then umm nope ;D

Here's a full HD Speccy video.. Enjoy some retro colour clash :))

Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: MrmediamanX on March 04, 2019, 03:10:42 AM
nice.
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: therevills on March 04, 2019, 03:50:26 AM
Cool! 8)
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Derron on March 04, 2019, 06:46:26 AM
I like the "gradient" the platforms upper and lower parts build - makes it look vibrant but still a bit more "3D" ("plastic"). It uses the limited color very well without trying to mimic "more colors".
Movement of the main char is pretty cute.


Hope you add a nice "swoosh" sound suiting to the particles when jumping.


bye
Ron
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Naughty Alien on March 04, 2019, 07:09:20 AM
..i like it .. and for some reason, i think zombies should be able to spit on to player...hehehe..thats how they look like to me when they move..lol
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Steve Elliott on March 04, 2019, 10:54:28 AM
Cool.  Neat particle effects too.
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: iWasAdam on March 04, 2019, 12:04:52 PM
Well cool, and again i'm with Steve - Great particles  8)
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Xerra on March 04, 2019, 05:18:26 PM
The death animation and those particles when you jump are excellent and it looks really clever the way you've mimicked the Spectrum colour clash. I'm curious how you're doing that? Are you drawing a coloured shader over elements of the sprite when it overlays an object that's coloured differently?

Next observation: You suck at playing your own game.

Further observation: This is going to be just as hard as games were back in those days and you shouldn't change this. I'll be shit at it but that's how the games were. They weren't so obsessed with games needing to be finished quickly so you'd go out and buy another one in those days.

Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on March 04, 2019, 05:36:41 PM
Quote
I like the "gradient" the platforms upper and lower parts build
Thanks, it was the only way I could add some form of shadowing without breaking the ZX 48k colour limit. Not that it matters anyway as part of my game is 128k mode.

Quote
i think zombies should be able to spit on to player...hehehe..thats how they look like to me when they move..lol
lol, when I drew them I wasn't sure if it was a zombie, a mummy or just a weird walking worm :P - Was supposed to be a zombie type thing though.

Quote
Cool.  Neat particle effects too.
Thanks, luckily it turned out OK as I was sceptical how it'd work due to the pixel size and no alpha blending / fading.

Quote
The death animation and those particles when you jump are excellent and it looks really clever the way you've mimicked the Spectrum colour clash. I'm curious how you're doing that? Are you drawing a coloured shader over elements of the sprite when it overlays an object that's coloured differently?
For the colour clash I found a super quick way to do it that has minimal impact on FPS as it really is just drawing the sprite again. In a nutshell every sprite and tile is white and I just set its colour before drawing. If a sprite goes over a coloured tile then it's a simple scissor command around that 8x8 grid area then draw the sprite again but set it colour to the background tile. Quick and simple :) - I tried other methods like grabbing the image and manipulating it but that was way too slow and also splitting each sprite into 8x8 but that's just more work.

Quote
Next observation: You suck at playing your own game.
I know :P I was messing around trying to do speed collection of gems while falling down to the next level.

Quote
Further observation: This is going to be just as hard as games were back in those days and you shouldn't change this. I'll be shit at it but that's how the games were.
It's not hard to play to be honest. Not super easy though but all you have to learn is when to jump over the enemies based on their speed. True this part of the game is more like the good old platformers that drove you nuts. Luckily it's not the full game so you not subjected to 50+ levels of madness.

Next video will be the ZX 128k part of my game, so no colour clash or 2 colours per 8x8 grid \o/ freedom!! :P
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: GaborD on March 04, 2019, 07:11:20 PM
Really like the particles and the strict oldschool coloring. Great contender.
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on March 04, 2019, 09:04:26 PM
Really like the particles and the strict oldschool coloring. Great contender.
Thanks, there's a lot more to it than currently shown ;D
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: 3DzForMe on March 04, 2019, 09:21:33 PM
I love the particle effects as he is generated and after he jumps, triple a stuff Indeed 8)
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: Qube on March 11, 2019, 01:55:09 AM
No new screen shots or videos yet, sorry :(

Tonight I've been creating ZX Spectrum 128k style music and my head is spinning with plink plonk sounds :)) - I so want to break out a full on synth VST but I'm trying to keep things authentic-ish. I'm sure all this effort won't be worth it as you'll all no doubt be frantically looking for the mute button but true to the Speccy days there is no mute button, so suffer  >:D >:D >:D

Less than 20 days left. Still lots to do and I hope I get some good flowing days where things just come together :-X
Title: Re: Qube's 8bit-wars comp entry - Untitled project
Post by: craigd on March 15, 2019, 03:08:45 AM
Looking good man! Not sure why but it reminds me of a cross between Chuckie Egg, Fred and Dizzy :}
Title: Re: ZX Collection Vol #1
Post by: Qube on March 30, 2019, 12:36:01 AM
Haven't shown much over the last few weeks but luckily I'm putting the finishing touches to it. Hopefully I'll be able to release it later today, a whopping 1 day early \o/ lol.

It's called "ZX Collection Volume #1" - 4 imaginary games from the ZX Spectrum 16K up to the multicoloured 128K.  The games in the collection are :

The logo looks odd as it's animated so looks better in motion.

(https://www.syntaxbomb.com/images/SBCompZXVol01.gif)
Title: Re: ZX Collection Vol #1
Post by: Steve Elliott on March 30, 2019, 08:23:03 AM
Cool, a bunch of games to play.   8)
Title: Re: ZX Collection Vol #1
Post by: Derron on March 30, 2019, 08:33:42 AM
The animated Logo seems to be ignoring the virtual resolution. Just follow the blue pixels of the "ZX" and you will see that the y-steps are way smaller than they should.


bye
Ron
Title: Re: ZX Collection Vol #1
Post by: Xerra on March 30, 2019, 12:13:56 PM
The animated Logo seems to be ignoring the virtual resolution. Just follow the blue pixels of the "ZX" and you will see that the y-steps are way smaller than they should.

Sigh, only Derron ....... :)

Looks great, boss. Gonna show us all up again?
Title: Re: ZX Collection Vol #1
Post by: Qube on March 30, 2019, 12:46:50 PM
The animated Logo seems to be ignoring the virtual resolution. Just follow the blue pixels of the "ZX" and you will see that the y-steps are way smaller than they should.
Is there a rule about that? Erm, no :P
Title: Re: ZX Collection Vol #1
Post by: 3DzForMe on March 30, 2019, 02:17:57 PM
Looks great, I'm beginning to think the resolution I've restrained myself to is a damn site smaller than I should be using. The speccy font looks huge compared to your menu, maybe it's just me. To late to address that now!
Title: Re: ZX Collection Vol #1
Post by: Derron on March 30, 2019, 02:37:09 PM
Is there a rule about that? Erm, no :P

There is no rule for that - but I was not sure if you were aware of it. Eg. in BlitzMax "plot(x,y)" or "drawLine(x,y,x2,y2)" ignore virtual resolutions - so they get "finer" than you want. I needed to add my own 2 cents (bresenham with drawRect() instead of plot()) to circumvent that issue.

Maybe this is the same for AGK (dunno how you did the pixel-look: scaling up or "virtual resolution with auto-scale up") ?


If I knew before that there is no much hassle (less than "only strict rule is the palette") then I could of course have rendered everything scaled up - but moved "unscaled" - so a smooth movement. :-)


Will check it out after compo deadline - kids are out now, 2 hours of coding for me ;-)


bye
Ron
Title: Re: ZX Collection Vol #1
Post by: 3DzForMe on March 30, 2019, 02:52:19 PM
My son's just requested MY 22 inch monitor back, so I'll be slumming it after lunch with 2 X 14 inches again  ^-^
Title: Re: ZX Collection Vol #1
Post by: Derron on March 30, 2019, 03:05:55 PM
14 inches - will help for the retro feeling :-)


bye
Ron
Title: Re: ZX Collection Vol #1
Post by: 3DzForMe on March 30, 2019, 03:23:17 PM
Come to think of it, I used to code on a14inch portable telly on the old spectrum, quite apt really
Title: Re: ZX Collection Vol #1
Post by: Steve Elliott on March 30, 2019, 03:23:53 PM
Quote
14 inches - will help for the retro feeling :-)

lol yes it does, my game running on the 13 inch MacBook looks more retro, although I prefer to run it on the bigger PC Screen with scanlines.
Title: Re: ZX Collection Vol #1
Post by: Qube on March 30, 2019, 05:04:10 PM
Quote from: Derron
There is no rule for that - but I was not sure if you were aware of it. Eg. in BlitzMax "plot(x,y)" or "drawLine(x,y,x2,y2)" ignore virtual resolutions - so they get "finer" than you want. I needed to add my own 2 cents (bresenham with drawRect() instead of plot()) to circumvent that issue.

Maybe this is the same for AGK (dunno how you did the pixel-look: scaling up or "virtual resolution with auto-scale up") ?
Yes, it's intentional :) - The game is using a virtual resolution of 256x192 but upscaled to native resolution. The scaling and rotation use native resolution as I didn't want to force that side into 256x192 as well.
Title: Re: ZX Collection Vol #1
Post by: Derron on April 12, 2019, 11:34:34 PM
When playing bomb da city I thought ... oh wait, throwing these bombs doesn't sound so ... "you should enjoy this game". Glad the police ... at least .. tries to arrest the pilot :-)
Think that game would even fit well to the Atari 2600.


The Bean game ... dunno how to describe it, I like these Dr.Mario-like games. Yet I have to add a critic here: I think the beans are too huge to "grasp" on a big screen. So playing this on a 24 (or maybe 27 inch or how big you filthy-rich-Mac-Users screens are  :-*) in fullscreen leads to pretty big circles in vibrant colors. Either it was the time of my tests (sparetime = evening) but it was hard to concentrate to see all cells/beans at once. Maybe this is why in Dr. Mario there is a bit of "environment" around (to lower playfield size).

Also I have to do a suggestion: if you remove beans, they just disappear, maybe make them blink shortly while they vanish: "blink blink collapse".


Other two games are ... nice and clean and crisp ... they play smooth and only stuff I have to add for now: dunno when you loose shield energy but I often killed stuff right before it reaches the outer circle - but it reached my ship already. I never really knew if it should remove energy if it hits me too - or if it just vanished because I hit it instead of shooting it down with my ammo.


bye
Ron
Title: Re: ZX Collection Vol #1
Post by: Qube on April 13, 2019, 12:17:26 AM
Quote
When playing bomb da city I thought ... oh wait, throwing these bombs doesn't sound so ... "you should enjoy this game". Glad the police ... at least .. tries to arrest the pilot :-)
I just fancied an excuse to remake the Blitz game from the Vic-20 :P - The public were all safe though as in the instructions the army cleared all the buildings ;D

Quote
The Bean game ... dunno how to describe it
A basic puyo puyo ripoff pretty well describes it :))

Quote
I think the beans are too huge to "grasp" on a big screen. So playing this on a 24 (or maybe 27 inch or how big you filthy-rich-Mac-Users screens are  :-*) in fullscreen leads to pretty big circles in vibrant colors
I'm a not so rich "27 inch filthy-rich-Mac-User" :o

Quote
Also I have to do a suggestion: if you remove beans, they just disappear, maybe make them blink shortly while they vanish: "blink blink collapse".
Yes, I was going to revisit this game a polish it up with sparkly effects. What happened was I did the Bomb da City game knowing I had plenty of time to revisit it and then a crap load of real life work came in so I didn't get time to do the sparkly effects :(

Quote
dunno when you loose shield energy but I often killed stuff right before it reaches the outer circle - but it reached my ship already. I never really knew if it should remove energy if it hits me too - or if it just vanished because I hit it instead of shooting it down with my ammo.
The blue circle is the "galactic shield" *cough* and the enemies drain that when they make contact. The players ship can't be destroyed as it's super hi-tech whereas the "galactic shield" isn't. Make sense?, good good ;D
Title: Re: ZX Collection Vol #1
Post by: round157 on April 13, 2019, 12:39:28 AM
This entry............Well Done.!
SimplePortal 2.3.6 © 2008-2014, SimplePortal