Field Hockey or Netball games

[sigh]

Looking at the courts special moves. This one as your goal semi circle reduce in size, making it harder for your opponent to get inside it to score:

You cannot view this attachment.

[sigh]

As the court size is 400x272, I was wondering; what other CPC games had larger screen sizes than the more common 320x200?

[Brundij]

I don't know. I'm not a fan of sports games, and this game may not be handled by a CPC, but I see potential for a retro style PC game with CPC aesthetics. Specially if as I see here, game and controls got this arcade feeling. Very similar to games like NBA Jam which is a game I like and played a lot despite not liking sport games.
It would be a pity to see all this work done going to waste. That said I'm not a programmer though so I can't help at all

[andycadley]

As the court size is 400x272, I was wondering; what other CPC games had larger screen sizes than the more common 320x200?

Not many and normally extended in one direction means compromising in another. 400*272 means you need a full overscan screen and that's half the system RAM gone purely on the screen display. Plus sprite routines get more complicated and potentially slower as a result, since you have both an awkward width and screen wrapping where the 16K boundary gets broken.

[sigh]

Uh oh. Well - looks like this was a serious waste of time. I wonder if the PLUS can handle that screen size? If not, it would mean that the game would have to scroll, which I really don't want.

Other option would be to redo it in 320*200 which is very small and that is all sorts of problems for the sprites.

[andycadley]

It's a lot easier on a Plus because you can use the screen splitting capability rather than having to rely on traditional overscan. And, of course, if you can get away with using the hardware sprites then you don't even have to worry about screen addressing as much anyway.

[eto]

If the screen is mostly static, I don't understand why it should impact speed if it's bigger than usual?! on a standard 64K machine I see some issues, but with a ROM game or RAM expansion, wouldn't there be options that make it possible?

Isn't it possible to have a continuous screen from &8000-&exxx? Sure, won't be able to use the firmware any more, but if it runs e.g. from ROM or loads all data into a Ram expansion, that should not be so important. And if that isn't possible, sprite routines (afaik) for 320 pixels usually already use lookup-tables. Is there really a huge difference between lookup tables for 320 or 400 pixels?

[andycadley]

Screen addressing gets kind of messy, because of where the wrap over occurs, usually mid line. You might be able to make it better by playing with the width a bit or using a rupture. It's not impossible to work around but it's definitely more complex, which is why you don't see loads of overscan games.

[Axelay]

If you aren't scrolling the screen then the simplest solution for an overscan screen is to start the first screen at an offset that ensures the start of the second bank of video memory also coincides with a new character line.  Then every byte you see on screen will be 1 memory location higher than the byte to its' left, just as on a standard 40x25 character screen.

If you use a lookup table to determine the y component of your screen addresses, then the entirity of your sprite code should probably be identical to that of a standard sized screen.  If you use calculations to determine the y component of a screen address, then you will need to add consideration for when the video memory jumps banks whenever you would also need to check for crossing character lines vertically, but traversing a line horizontally would remain as simple as with a standard screen.

[sigh]

If you aren't scrolling the screen then the simplest solution for an overscan screen is to start the first screen at an offset that ensures the start of the second bank of video memory also coincides with a new character line.  Then every byte you see on screen will be 1 memory location higher than the byte to its' left, just as on a standard 40x25 character screen.

If you use a lookup table to determine the y component of your screen addresses, then the entirity of your sprite code should probably be identical to that of a standard sized screen.  If you use calculations to determine the y component of a screen address, then you will need to add consideration for when the video memory jumps banks whenever you would also need to check for crossing character lines vertically, but traversing a line horizontally would remain as simple as with a standard screen.

Yes - I am not scrolling the screen. How much extra work is your conclusion compared to a standard screen and is it painful for a coder?

Is is doable on 64kb with this method, or would the game need to be 128kb? I really would prefer 64kb as I would love to enter something like this in a future CPC Retro dev.

I took one of the courts and made a quick and dirty 320x200 by cropping and scaling with the sprites on top. The sprites in yellow have been fixed back into their wide pixels, but the rest of the sprites are all messed up. It already shows how much the court would need to be sacrificed.

You cannot view this attachment.

[Axelay]

Where things get painful with what you are asking for is in memory management, unfortunately.

I believe you said you had 24kb of sprite frames.  The overscan display you have specified is 24kb.  It is actually 'spread out' over 32kb with lots of annoying little memory gaps you can try and use, or you could try changing character height to make using that free memory easier, but that would impact on the screen size a little.  For the sake of the argument, it's about 24kb.

The retro dev comp requires single load 64kb games, and for just the screen and sprite frames you've consumed 48kb already, leaving 16kb for background graphics (with varied courts), game logic, sound/music and some memory for a menu interface.  In my view, that simply isn't close to being possible without really savage cut backs on the sprite animation, screen size and court variety.  So in its' present form, I think it would have to be 128kb.

A point on the screen size, you mentioned using a 400x272 display.  The overscan displays I have used are at 384x272, and even then, most of the two character columns on the left and right sides of the screens will not be visible on an original CTM.  At least not mine.  With how you have placed the goals, I think it likely they would both be at least partly offscreen.  Also, while most of the 272 lines in height of an overscan screen is visble, towards the corners there's enough of a curve to start obscuring the top and bottom lines, so I suspect the left part of your score line would not be entirely visible either.

[sigh]

Where things get painful with what you are asking for is in memory management, unfortunately.

I believe you said you had 24kb of sprite frames.  The overscan display you have specified is 24kb.  It is actually 'spread out' over 32kb with lots of annoying little memory gaps you can try and use, or you could try changing character height to make using that free memory easier, but that would impact on the screen size a little.  For the sake of the argument, it's about 24kb.

The retro dev comp requires single load 64kb games, and for just the screen and sprite frames you've consumed 48kb already, leaving 16kb for background graphics (with varied courts), game logic, sound/music and some memory for a menu interface.  In my view, that simply isn't close to being possible without really savage cut backs on the sprite animation, screen size and court variety.  So in its' present form, I think it would have to be 128kb.

A point on the screen size, you mentioned using a 400x272 display.  The overscan displays I have used are at 384x272, and even then, most of the two character columns on the left and right sides of the screens will not be visible on an original CTM.  At least not mine.  With how you have placed the goals, I think it likely they would both be at least partly offscreen.  Also, while most of the 272 lines in height of an overscan screen is visble, towards the corners there's enough of a curve to start obscuring the top and bottom lines, so I suspect the left part of your score line would not be entirely visible either.

Thank you.

For the 64kb, it would have been just a single court with the sprites to show (with the other courts being multiload at a later point) to get it into the comp.

Your point about the goal nets not being visible on the original displays, says pretty much everything about the game in it current form, in that I have failed to have realized this, making this current sized whole single screen set up redundant.

It's now more obvious now that the game will need to be 320x200 to avoid any scrolling. *

So - if I were to reduce the size to 320x200 as in the last pic I posted (no scrolling) and just had the same amount of sprite animations, I'm guessing that this would fit on a 64kb?

As long as the animation is still there to keep the energy in the game, I think I would be okay with that. Also - if I want to entice a coder to give this a go, I want to make it not too complicated, due to it being entered for a 64kb comp, as getting the interest for a netball game in itself is already challenge.


* Actually - what is the largest screen size I could fit the court in that would show on an original monitor without losing the edges please? Something like 350x250?

[Axelay]

So - if I were to reduce the size to 320x200 as in the last pic I posted (no scrolling) and just had the same amount of sprite animations, I'm guessing that this would fit on a 64kb?

I couldn't say for certain, but it sounds more achievable, when taken with the cutting back to one court.

* Actually - what is the largest screen size I could fit the court in that would show on an original monitor without losing the edges please? Something like 350x250?

Here's some test shots from the megablasters tribute so you can judge for yourself, one emulator and one photo from my CTM.  They were taken at different stages before things were finalised, so the panel isn't identical, but the placement didn't change. The display is 384x272.  Note that on the emulator shot, half a character on the left side is unused because of the odd tile width, as is half a character along the bottom so score information is not obscured.  I'd guess that by removing a character from all four sides on the emulator image, so 368x256, you would probably only lose a little from the top and bottom corners on the right hand side from the CTM.

If you are going target 128k, there's no reason you couldn't use the full 384x272, you just need to bear in mind the curve of the CTM frame, and that very little of the left and right most character columns is visible, so it would need to be non essential graphics you'd only see on emulators or real hardware on alternative displays.

[sigh]

So - if I were to reduce the size to 320x200 as in the last pic I posted (no scrolling) and just had the same amount of sprite animations, I'm guessing that this would fit on a 64kb?

I couldn't say for certain, but it sounds more achievable, when taken with the cutting back to one court.

* Actually - what is the largest screen size I could fit the court in that would show on an original monitor without losing the edges please? Something like 350x250?

Here's some test shots from the megablasters tribute so you can judge for yourself, one emulator and one photo from my CTM.  They were taken at different stages before things were finalised, so the panel isn't identical, but the placement didn't change. The display is 384x272.  Note that on the emulator shot, half a character on the left side is unused because of the odd tile width, as is half a character along the bottom so score information is not obscured.  I'd guess that by removing a character from all four sides on the emulator image, so 368x256, you would probably only lose a little from the top and bottom corners on the right hand side from the CTM.

If you are going target 128k, there's no reason you couldn't use the full 384x272, you just need to bear in mind the curve of the CTM frame, and that very little of the left and right most character columns is visible, so it would need to be non essential graphics you'd only see on emulators or real hardware on alternative displays.

Thanks you for the images, I really appreciate it. I see what you mean now by the bending on the CTM.

I have posted an image of a screen 368x256. 

You cannot view this attachment.

I had to bring in the goal nets in by a few pixels, as the original width of the playable area court is 376x190. This new pic shows 368x190. The goals are a tight fit as I had to remove the empty space either side. Before I go any further editing all the other courts, I just want to know if this is also achievable for a 64kb comp?

I realize that will be difficult to answer, but all the other games like the scrolling beat em up/football etc; have all required 128kb, so the 64kb is something I haven't achieved yet.

[Brundij]

Not sure if it helps but this game runs in a CPC 464 with a full overscan screen. Maybe it's simpler than a netball match but it can be done.

For speed the game could be a 2 vs 2 instead of full teams or something like that. I don't know the rules of netball.

[sigh]

Not sure if it helps but this game runs in a CPC 464 with a full overscan screen. Maybe it's simpler than a netball match but it can be done.

For speed the game could be a 2 vs 2 instead of full teams or something like that. I don't know the rules of netball.

Thanks. I think that game is 384x270.

I'm strongly leaning to a format like 330x210 instead, which will mean having to redo the sprite animations to make them smaller. I'm hoping that the extra 10 pixels on the horizontal and vertical doesn't kill the speed too much.

You cannot view this attachment.

With netball, you cannot move with the ball like you can in basketball. Once you have the ball in your hands, you have to stay put and throw it within 3 seconds. A 2 vs 2 netball, wouldn't work for this reason. It works in basketball because you are dribbling all over the place which means your opponent has to guess whether you are going to keep dribbling or throw it to your partner.
Netball wouldn't have that guess work with only 2 vs 2 because you have no choice but to throw it to your team mate once you have the ball. All the guess work in netball comes with the full 7 vs 7.

[Axelay]

I had to bring in the goal nets in by a few pixels, as the original width of the playable area court is 376x190. This new pic shows 368x190. The goals are a tight fit as I had to remove the empty space either side. Before I go any further editing all the other courts, I just want to know if this is also achievable for a 64kb comp?

I realize that will be difficult to answer, but all the other games like the scrolling beat em up/football etc; have all required 128kb, so the 64kb is something I haven't achieved yet.

Reducing the screen size by a small amount from full overscan doesn't reduce the memory used by the screen all that much, so I don't think it changes the equation that much.  I'd still lean towards probably not in 64k, but just possibly with large compromises to how you're envisaging it.  That's just my take on it though.

Regarding Oscar Z, it is not using full overscan.  It has a 'standard' 16kb screen for the play area, stretched to the monitor sides and reduced in height.  It then has a status area which is an additional screen of less than 4kb I think, floating several characters above the play area.  The border above and below this is set to the same colour as the play area sky to make the sky appear to extend to the top.

[sigh]

I had to bring in the goal nets in by a few pixels, as the original width of the playable area court is 376x190. This new pic shows 368x190. The goals are a tight fit as I had to remove the empty space either side. Before I go any further editing all the other courts, I just want to know if this is also achievable for a 64kb comp?

I realize that will be difficult to answer, but all the other games like the scrolling beat em up/football etc; have all required 128kb, so the 64kb is something I haven't achieved yet.

Reducing the screen size by a small amount from full overscan doesn't reduce the memory used by the screen all that much, so I don't think it changes the equation that much.  I'd still lean towards probably not in 64k, but just possibly with large compromises to how you're envisaging it.  That's just my take on it though.

Regarding Oscar Z, it is not using full overscan.  It has a 'standard' 16kb screen for the play area, stretched to the monitor sides and reduced in height.  It then has a status area which is an additional screen of less than 4kb I think, floating several characters above the play area.  The border above and below this is set to the same colour as the play area sky to make the sky appear to extend to the top.

Aaah okay, thanks.

Hmmm...

I have done this dirty version where I have shrunk the whole court to fit into 320x200 and re-pixeled the sprite (the orange animated ones) to the same size as the reduced green ones as much I could. I still have around 2/3 of anims left to re-pixel. Once the skips are re-done, things will be much easier as the locomotion sets are the most tricky:

You cannot view this attachment.

This version is also 320x200, but I have made the playable area of the court bigger.

You cannot view this attachment.

...and then this this 330x210 - 10 extra pixels on top and bottom(5 pixels on either side)using the same reduced sprite examples (the animated ones). The actual playable area of the court is 320x162:

You cannot view this attachment.

I want to keep it 64kb.  Ideally I would prefer to use the 330x210 in 64kb. Failing that, it will have to be the second image with the enlarged playing area inside the 320x200.

Is the 330x210 okay for 64kb? How much difference would the extra 10 pixels(memory etc) make compared to the standard 320x200? 

[eto]

Will the additional 8KB for the screen really make this impossible? If the release for CPC retrodev limits courts and music tracks, couldn't it fit into 64KB? And then an enhanced release that e.g. can load court data/music from disc.

[sigh]

Will the additional 8KB for the screen really make this impossible? If the release for CPC retrodev limits courts and music tracks, couldn't it fit into 64KB? And then an enhanced release that e.g. can load court data/music from disc.

For CPC retrodev, it would just be the one court.

Afterwards, an enhanced release with all the other courts loaded from disk, is what I would like to see follow.

[andycadley]

In terms of screen memory the equation that matters is (assuming X is measured in Mode 1 pixels):

(X / 4) * Y

If that number is over 16384, then you have to use overscan to get a 32K screen. The difference between that number and 32768 will be the amount of "screen memory" that isn't actually visible, but it won't be contiguous as you'd have to work around the screen memory layout.

Edit: it's also worth noting that the horizontal size has to be a multiple of 8 Mode 1 pixels, so it'd need to be 336 * 210 pixels.

[sigh]

In terms of screen memory the equation that matters is (assuming X is measured in Mode 1 pixels):

(X / 4) * Y

If that number is over 16384, then you have to use overscan to get a 32K screen. The difference between that number and 32768 will be the amount of "screen memory" that isn't actually visible, but it won't be contiguous as you'd have to work around the screen memory layout.

Edit: it's also worth noting that the horizontal size has to be a multiple of 8 Mode 1 pixels, so it'd need to be 336 * 210 pixels.

Thanks.

I used the formula and the 336 * 210 was 17640 - well over the 16000 of the 320*200.

Well - that's solved then; 320*200 it is then. I'm halfway through redrawing the sprites; after they are done, I will then clean up the backgrounds. 

[Brundij]

It'll lose charm but you could avoid to draw the area of the crowd and scoreboard and use a floating scoreboard or one that appears only when a team scores. Again is the only example I know but just as NBA Jam does. (it's true however that there was always a timer and a scoreboard in the table at the back)
This way the court and sprites can be a bit bigger and lose less detail.

[sigh]

It'll lose charm but you could avoid to draw the area of the crowd and scoreboard and use a floating scoreboard or one that appears only when a team scores. Again is the only example I know but just as NBA Jam does. (it's true however that there was always a timer and a scoreboard in the table at the back)
This way the court and sprites can be a bit bigger and lose less detail.

Thanks.

I think having a floating scoreboard will mean having to constantly update it as it moves over sprites and background. It would be less stressful on the cpu to just have it on a static blank portion at the bottom of the court. As the court has no scrolling so the sprites won't get any larger.

[Brundij]

Oh well I didn't notice the bottom scoreboard in the third image, my bad.

Ok, my last 2 cents here. If it ends being a 320x200 screen maybe a bit of scroll is not a problem anymore both vertically and horizontally. You can keep the original size of the court and just scroll a bit when a team is at the leftmost or rightmost part of the court same for up and down.