This is probably in the wrong place , but heyho , Administrators feel free to put in the right area.
I was having a think about Hardware scrolling and wondered whether it was an expensive thing to add to a machine ,back in the early 80's. I think had the Amstrad been given proper hardware scrolling (To the level of the c64) it would have been a better machine or on par with the C64(Mind you it has the Sid chip too, so maybe not). Obviously it must have been an expense that Amstrad could not make competitively. If anyone on here has understanding of this could explain , that would be great. Anyway whilst thinking about it I wondered whether anyone had thought about making it available on say an emulator , so that games could be programmed utilising this feature ? Or is this Sacrilegious and a ridiculous suggestion , that shall remain merely a dream?? Oh and I know the Plus range has hardware scrolling doesn't it? But is really isn't in the same league as the C64 is it?
Quote from: Puresox on 20:41, 13 December 13
This is probably in the wrong place , but heyho , Administrators feel free to put in the right area.
I was having a think about Hardware scrolling and wondered whether it was an expensive thing to add to a machine ,back in the early 80's. I think had the Amstrad been given proper hardware scrolling (To the level of the c64) it would have been a better machine or on par with the C64(Mind you it has the Sid chip too, so maybe not). Obviously it must have been an expense that Amstrad could not make competitively. If anyone on here has understanding of this could explain , that would be great. Anyway whilst thinking about it I wondered whether anyone had thought about making it available on say an emulator , so that games could be programmed utilising this feature ? Or is this Sacrilegious and a ridiculous suggestion , that shall remain merely a dream?? Oh and I know the Plus range has hardware scrolling doesn't it? But is really isn't in the same league as the C64 is it?
to make it work correctly you would need to delay x number of pixels, and you would need potentially 2 bytes more of storage which you could shift into.
Gate-Array already has 2 bytes storage, so another 2 may have taken it over the gate-count that they could have had at the time???
If it was added to an emu, the emu is no longer emulating a true cpc.
In addition if it was added to existing games, they now play a little different because the scrolling is a different speed.
Enjoy the Plus which has soft scroll.
Quote from: arnoldemu on 21:11, 13 December 13
to make it work correctly you would need to delay x number of pixels, and you would need potentially 2 bytes more of storage which you could shift into.
Gate-Array already has 2 bytes storage, so another 2 may have taken it over the gate-count that they could have had at the time???
If it was added to an emu, the emu is no longer emulating a true cpc.
In addition if it was added to existing games, they now play a little different because the scrolling is a different speed.
Enjoy the Plus which has soft scroll.
EDITs:
The CRTC tells the Gate-Array which pixels to read. Gate-Array reads 2 bytes and stores them internally, then it sends these out to the tv/monitor.
In order to do pixel scroll it needs to delay by x pixels (x where you program it). To do this it now needs more than 2 bytes, and it needs a register to define the scroll value. Both of these take silicon.
It's not known if they reached the limit of gates in the gate-array or not.
So potentially it could have been more expensive to do because of the extra gates required.
I wish they had considered it though.
I don't see the point personally. If you want a computer to behave like another computer, then you might as well just use the other computer. The CPC can do a decent enough job of scrolling when done right anyway and the fact it uses software to achieve it shows what a decent machine it really is.
the CPC can scroll better than MSX1&2... :P
Also what you are asking for does exist, it is called the Amstrad PLUS...
Anyway I think Hardsprites would be more interesting than scrolling.
The CPC has proper hardware scrolling. Examples are Relentless, Tornado Low Level, Mission Genocide and others.
The problem is that game companies forced coders to do dirty speccy ports instead of doing a proper rewrite for the CPC.[nb]If you got 3 weeks then you can't do much in that time. >:( [/nb]
One thing i'm thinking about at the moment, but not sure it can be possible : some card that would enable to use 2 amstrad on the same screen at the same time.
One would be overlayed on the other (one of it's ink being transparancy then) thx to some video incrustation device.
Both machines would be connected and somewhat synchronised so sounds and video would be mixed.
as a result one of the CPC would be used for background, the other for foreground, meaning some sort or sprite layer.
This would constitute a "machine" or system closer to some arcade systems, with 2x Z80, background and foreground, 2x AY sound and so on... would have like 256K RAM in case you get 2x6128... but a 464 could really suffice as secondary machine.
As each CPC/PLUS would only manage one layer, less need to mask spries or whatever... you be sure they are well synchronised and the video is well aligned on the same screen.
Could even be fun to program or to design games/graphics for...
Imagine Mode1 in 4+3 inks... (plus rasters)
Or 2x Amstrad 6128 PLUS would make quite a nice system indeed..
The good point with such a method is that you don't really modify the original system/computers, you just cumulate 2 machines in one...
The card would just be a mixer for both Video and Sound, and would just link the Amstrads together (like some Memory handshake, common timer/clock or network...).
The rest would just need a good programation and mastering of timers on both machines I guess.
Amstrad Hardware scrolling was a little on the fast side , Relentless and Mission Genocide are probably the best examples of good scrolling on the Amstrad , it amazes me that more wasn't done with the Technique used by Mission Genocide?
Quote from: Puresox on 20:41, 13 December 13
Oh and I know the Plus range has hardware scrolling doesn't it? But is really isn't in the same league as the C64 is it?
The only nice thing about the C64 over the plus is that it's display is character based rather than a straight bitmap, which allows for a lot of clever little effects. In every other respect it's really not even near to the same league as the Plus range from a graphical perspective. It's still a real shame that people haven't tried making more of the range.
If you were to try and retro-fit hardware scrolling onto the CPC, you'd do it in the way Arnoldemu describes which, oddly enough, is basically what the Plus hardware is doing. So why emulate a fake machine when the real thing exists?
I am not technically minded in a computer sense , So I am speaking from just a gamers perspective And I have to say that I have not seen scrolling as good on a plus machine as I have seen on a C64 . But I am not going to argue the point as this is all hypothetical. It was just a musing I had. And wondered whether I could find out a reason why it wasn't implemented to a greater extent on the original machine. Obviously it must have been down to cost , I do not know how or what technology gives the C64 it and the CPC not. Appreciate your inputs though( although It is difficult for me to totally understand , some of it makes sense ;D )
QuoteAmstrad Hardware scrolling was a little on the fast side , Relentless and Mission Genocide are probably the best examples of good scrolling on the Amstrad , it amazes me that more wasn't done with the Technique used by Mission Genocide?
First I think Vertical and Horizontal are two very different things.
And quite some games managed to show CPC can somewhat scroll well.
But I guess to use a 128K CPC can greatly help, just because it eases for some RAM intensive tricks : double buffering, tileset with a pixl shift and so on...
isn't vertical scrolling easier ?
QuoteAnd I have to say that I have not seen scrolling as good on a plus machine as I have seen on a C64 .
Saddly the PLUS never got decent specific horizontal shooters, nor even vertical ones...
let's see :
=Mistycal : a straight disk to cartridge CPC port.
=Copter 271 : an unfinished game with lot of design flaws to begin with.
128K onlycartridge, and unfinished, uses a horizontal scrolling that only plague the game (which is a vertical scroller actually), too heavy use of the hardsprites, annoying palette and noise...
that's all that can be considered " 2D shooters" and both are vertical.
Robocop has a sweet multidirectionnal scrolling indeed.
Quote from: Puresox on 18:16, 14 December 13
It was just a musing I had. And wondered whether I could find out a reason why it wasn't implemented to a greater extent on the original machine. Obviously it must have been down to cost
If you look at the simple kinds of games that were appearing on the home computers in the very early 80's, even on the C64, then scrolling games don't seem to be very common, so per pixel scrolling may just not have seemed important at the time they were designing the CPC.
I'm not convinced per pixel hardware scrolling made easy on the CPC would have changed very much though. Consider how many spectrum ports were modified only so far as to get a spectrum game running on the CPC, with little or no alterations or optimisations to make better use of even the CPC464, let alone later CPC models. There's also the parallel on the Amiga where despite having hardware scrolling and a blitter, many games were clearly not running as well as others, making them reasonably obvious ST ports that had made no use of the Amiga hardware except where they had no choice but to change things. So I dont think much would have changed if the CPC had possessed easy per pixel hardware scrolling, because it would have required far too much rewriting of the spectrum code base most developers were starting from to take advantage of it. Though I gather French CPC games were not usually ports from anything, so they may have ended up an exception.
Quote from: arnoldemu on 21:11, 13 December 13
If it was added to an emu, the emu is no longer emulating a true cpc.
I would agree that a real CPC would have to demonstrate this scrolling, it's bad enough that an emulator can run beyond the 4Mhz limit. ;D
Actually I take it back , The scrolling on Navy Seals is pretty good . And just as good as C64's .
Because it use the PLUS hardware scroll.
Quote from: Puresox on 18:05, 15 December 13
Actually I take it back , The scrolling on Navy Seals is pretty good . And just as good as C64's .
I know people frown at "Green Beret" if that game is similar to "Navy Seals", personally I'm one of the few (if not the only one) that isn't bugged by the scrolling in GB, though I guess it could be a bit crude for the time period it came out in.
@Axelay, I would love to see what game you would make if you used CPC smooth vertical scrolling.
Do you have some code that can do it? I can provide some if you need some ;)
I once asked Axelay to do a vertical shooter, but he said no !
:'(
Maybe i'm wrong, i asked Fano...
:)
But the answer was : do it yourself !!
;)
It's true that a shooter with vertical hardware scrolling using two screens and CRTC reg 5 would be great !
Quote from: Xifos on 13:14, 20 December 13I once asked Axelay to do a vertical shooter, but he said no !
Maybe i'm wrong, i asked Fano... But the answer was : do it yourself !!
They are greats! 8)
Bullet Hell!
It would be nice to see something "Cave" shooter like on the CPC., with it's vertical scrolling.
Don't dream... Cave games "like" are maniac shooters with tons of bullets.
The CPC is not the good hardware for that.
But, nice 80's hard vertical scrolling games can be done w/o problem.
Just do it... Because, more peoples done things on CPC and more the computer will stay alive.
Quote from: arnoldemu on 23:17, 13 December 13
EDITs:
The CRTC tells the Gate-Array which pixels to read. Gate-Array reads 2 bytes and stores them internally, then it sends these out to the tv/monitor.
In order to do pixel scroll it needs to delay by x pixels (x where you program it). To do this it now needs more than 2 bytes, and it needs a register to define the scroll value. Both of these take silicon.
It's not known if they reached the limit of gates in the gate-array or not.
So potentially it could have been more expensive to do because of the extra gates required.
I wish they had considered it though.
well, commodore, desing and manufacture their own chips. They can desing 1000k or 2000k gate array with the only limit of their manufacture tecnology. Amstrad needs subcontract it to ferranti. So they are limited to ferranti products capacity. Original Gate array is based in 5000R series ula with 2000 gates max capacity.
Ferranti have 4000 and 10000 gates model, but ther appeared later in market ,In the begining 2000 gates are the maximal offecered, so depend on ferranty 4000 gates time and time cpc development. Mayme amstrad is limited to 2000 gates or, maybe is limited to gate array cost or heat cost.
Well it would be great to add more features, and though it's a lot of work we can dream right? (what a christmas present that would be!).
I guess you'd need to reimplement the gate array and add more features. Maybe a small FPGA in DIP format (like this http://www.digilentinc.com/Products/Detail.cfm?NavPath=2 (http://www.digilentinc.com/Products/Detail.cfm?NavPath=2),400,798&Prod=CMOD) but you'd need to add 5V and the correct pinout. Or a 40 pin PLD/CPLD (I found the Atmel ATF2500C), but I guess it might need some pinout adapter or something.
Of course, finding the hardware is easy... making it work is something else completely.
Quote from: TotO on 15:11, 20 December 13
Don't dream... Cave games "like" are maniac shooters with tons of bullets.
The CPC is not the good hardware for that.
Do you talk about Shumps? I guess I miss the point somehow. Do you have a youtube link for an example?
Cave games are maniac shooter only. You can type "CAVE shooters" in youtube to die.
Here, one of them to understand:
DoDonPachi DaiFukkatsu Black Label Zatsuza [high quality] (http://www.youtube.com/watch?v=ZHqN_fH2S7k#)
No, it's definitively not possible to do that on CPC! :-\
I think the moniker "bullet hell" is quite appropriate for these kinds of games. I just don't enjoy them at all... even though I find a lot of "instant death" games too hard, I prefer to die and learn to avoid that thing in the future than just have a health bar deplete slightly and not know if that's the correct place to be or not.
That said, they're usually pretty to look at, even if it's hard to figure out what's actually going on!
The thing about those games is that usually you only die if a bullet hits your ship's cockpit. The impact zone is pretty small, regardless the size of your ship. That is what allows you to avoid the bullet courtains. That and your memory and reflexes.
I like Cave's Donpachi games a lot ;D
I adore the Cave games too with my top 3 being :
Ketsui (Brilliant score mechanics. My favourite cave game)),
Esp.Rade(great design, but not so great score mechanics) and
Dangun Feveron(addictive score mechanics, but not quite so good ship speeds)
I wonder if something less bullet intensive like Raiden Fighter would be doable? It would also be really good to see more 2 player options.
Yes, the collide mask of the ship and of the bullets are both smalls. (so you think that you are good, but... no)
On CPC, it will be more easy to compute and display area w/o bullet than the invert. ;D
Maybe something with less detailed graphics is possible, like one of those abstrac shooters with vector graphics for the pc.
The problem is not the detailed graphics, but the quantity of sprites to handle.
No fan of Bullet hell games here also. Not my idea of fun learning your hit box and remembering patterns just doesn't do it for me , I prefer an R-Type shooter or 1943 style
Me too ! :D
A nice vertical classic shooter is Flying Shark... On arcade, sure. 8)
Quote from: arnoldemu on 11:47, 20 December 13
@Axelay, I would love to see what game you would make if you used CPC smooth vertical scrolling.
Do you have some code that can do it? I can provide some if you need some ;)
Yes, I have some code that does that, thanks. :)
Quote from: Xifos on 13:14, 20 December 13
I once asked Axelay to do a vertical shooter, but he said no !
But not 'never', right? ;)
I was just telling stories in order to convince you to do it.
(did it work ?)
:)
Thank god bullet hell shooters are not possible on the CPC. I don't feel *that* masochistic!
Interesting.
I adora bullet hells (am crap at them)but I understand the sentiments. I just find that bullet hell shooters usually have some of the most entertaining score mechanics.
Manics are a visual fascination for me (DonPachi series are eye sugar) but i don't like playing them because there are very disturbing with so small hit box, i am not able to asbtract the whole ship so i suck at this :(
Problem on CPC is to process so much bullets, not only drawing but computing coords, checking bounds and testing against player box, you may manage 32 of them but no more i think (with managing the other objects like enemies,player and player weapon)
Quote from: fano on 07:21, 24 December 13
you may manage 32 of them but no more i think (with managing the other objects like enemies,player and player weapon)
How big would the sprites have to be in order to acommodate 32?
Difficult to reply as that depends of used method (compiled sprites,dual playfield) and screen refresh rate (50hz or 25hz)
If your game runs at 50Hz , you can alternate player shots and bullets each frame , they will blink fast so that would not be a big problem.For sure , the most adapted machine to do a vertical shooter with a maximum of bullet would be the 6128 Plus as you have 'just' to concentrate your efforts on bullets/player shots rendering.
Okay. How about this scenario:
(http://i.imgur.com/E6K4jsu.gif)
This is an unfinished mock up and the score mechanics were never really worked out, but it was to be something like a watered down mechanic of Ketsui and Dangun Feveron, with both players sharing the score.
I actually had started on a mode 1 mock up in order to have more elaborate special effects.
Playfield is 160x200 using mode 0 graphics and a 2 player mode. Game would be 64KB Disk or 128KB disk (with extras of course and bosses loaded in seperately). This mock up shows 7 sprites:
Player ships = 2
Bullet = 4
Power Up = 1
The laser would have to be made up of many other sprites (maybe 6).
Explosions could be around 9 sprites - 3 frames small, 3 frames medium, 3 frames large; mixing and matching to create exploding effect. Expect slowdown when things get busy, but that is standard in all "Cave" type games.
Then the enemies and 1 round enemy bullet.
All this running at 25hz.
I know that the picture doesn't really show much, but I'm wondering if a bullet fest "could" be possible and playable to a decent speed.
Where are the enemies, and their bullets ? ;D
Probably not a so easy task for the CPC... But, if you done a vertical scrolling shumps, use a 128x256 screen area instead.
Quote from: TotO on 14:06, 24 December 13
Where are the enemies, and their bullets ? ;D
Probably not a so easy task for the CPC... But, if you done a vertical scrolling shumps, use a 128x256 screen area instead.
True indeed! I didn't get to do the enemies and bullets, so I guess it was pretty pointless for me to post that picture! :D
But why the 128x256 format? It seems rather thin on the width, not giving enough room manouverability.
For a vertical shooter, a 128x256 screen (MODE 0) look overscan and allow display optimizations.
Quote from: Xifos on 19:38, 23 December 13
I was just telling stories in order to convince you to do it.
(did it work ?)
:)
Hard to say. I've always wanted to make a vertical shooter, or three, anyway! :)
Well, hum...
I put a dsk with a little try.
overkill.dsk (run "overkill")
But i think i'm not good enough to do things properly.
Dealing with interrupts and crtc is too much for me.
I am not even sure if it works on real hardware...
It works good in winape, and strangely in wincpc...
;)
Hey, this is actually a really good start! The sprite is the perfect size, and I love the colours in the background :D
Is it possible to fix the charater-based tile appearance at the top?
That's the problem.
I have trouble with my two screen setup and reg5.
Maybe i could draw lines instead of putting tiles...
What if you masked it behind something else?
Quote from: Xifos on 19:21, 25 December 13
Well, hum...
I put a dsk with a little try.
overkill.dsk (run "overkill")
But i think i'm not good enough to do things properly.
Dealing with interrupts and crtc is too much for me.
I am not even sure if it works on real hardware...
It works good in winape, and strangely in wincpc...
;)
Looks like a promising start to me. :) Unfortunately I dont have access to a real CPC to test it on right now...
Quote from: Xifos on 20:08, 25 December 13
That's the problem.
I have trouble with my two screen setup and reg5.
Maybe i could draw lines instead of putting tiles...
Another option might be to put a pause in the very first interupt and have it blank all the colours at the start, wait until the lowest position of the top of the screen, then set the colours to what they're supposed to be. Or even set to mode 2 at the beginning of the screen, then back to the game mode at the point you want the top of the screen to appear, and you'll only need blank colour 1, if colour 0 and the border are the same. This would tie up a good chunk of cpu time, so you'd want to find some fixed length processes to put in there, like key scanning or score display update or maybe background tile writing.
Writing the tile background one line at a time every frame might have another benefit though, because writing a large chunk of the background every so often may cause a spike in the CPU load big enough to interfere with the frame rate.
Thanks.
:)
I'm just doing tests here.
So there are too many c parts (using sdcc), and i am using the firmware.
I was just wondering how they did with mission genocide and warhawk ?
(it's perfectly done even at the top of the screen)
EDIT : argh, i had a look at my code, and i realize i was not putting the right values for r5 !
It was between 0 and 8, instead of 0 and 7 !
The result cannot be good !
Here's another version.
This time the crtc values for r5 are good (you can see it at the sprite moving at the same rate of the scrolling)
I set the inks at black at the top, but it's not perfect.
For this kind of games, i guess i have to avoid sdcc and the firmware...
:(
That is looking very nice indeed!
Are you planning to implement a slight left and right horizontal scroll?
I know that some vertical shooters have a slight horizontal scroll.
But i don't know how i could do that in hardware...
I'm not even sure to be able to put others sprites and stay at 50 hz !
;)
That's looking great! Cheers for the taster.
Just a question about the movement of the craft. I have noticed on a lot of vertical scrolling shooters on the Amstrad, that left and right movement seems spot on , but along the horizontal axis , the movement is laboured and not as quick. I know it may be partially optical illusion due to the scrolling giving false effect . Is this a limit or can it be altered?
Quote from: Xifos on 09:52, 26 December 13
I was just wondering how they did with mission genocide and warhawk ?
(it's perfectly done even at the top of the screen)
If you look closely at the top of the screen in Mission Genocide, you can see the sprites emerging from the top of the screen extend above the top of the background by up to one character. So that suggests there's a blank line written to the screen memory before it appears on screen, and the new background written line by line at the lowest point the top of the screen appears, giving the impression of a static screen top. But nothing has been done to mask the sprites, perhaps because it isnt as noticable on a real monitor compared to in an emulator.
Quote from: sigh on 20:12, 26 December 13
Are you planning to implement a slight left and right horizontal scroll?
Adding that to a vertical scroll on the CPC would negate the optimisation benefits to the sprite code of having a 64 byte wide screen.
Quote from: Puresox on 22:07, 26 December 13
Just a question about the movement of the craft. I have noticed on a lot of vertical scrolling shooters on the Amstrad, that left and right movement seems spot on , but along the horizontal axis , the movement is laboured and not as quick. I know it may be partially optical illusion due to the scrolling giving false effect . Is this a limit or can it be altered?
I'm not sure, are you talking about the fact horizontal movement for the sprite is byte/byte instead of pixel/pixel ?
Quote from: Axelay on 05:04, 27 December 13
Adding that to a vertical scroll on the CPC would negate the optimisation benefits to the sprite code of having a 64 byte wide screen.
Okay.
Quote from: Xifos on 09:58, 27 December 13
I'm not sure, are you talking about the fact horizontal movement for the sprite is byte/byte instead of pixel/pixel ?
What'a happening is that up and down movement speed of the ship is different from the left and rigt movement speed. Could this be solved by having the ship move by 4 horizontal pixels?
I'm seriously looking forward to this game. I always wanted to see more smooth vertical scrolling shooters on the CPC.
Boy, and to think I found Lightforce to be smooth back then...
https://www.youtube.com/watch?v=NGzpEfp_6jo
And 1943: [Amstrad Cpc] 1943 Longplay (http://www.youtube.com/watch?v=HQR1KXb8vDI#)
That's software scrolling, not hardware.