News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

New Plus Series Game a Proposal

Started by dcdrac, 21:09, 15 August 13

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

arnoldemu

Quote from: dcdrac on 17:56, 31 August 13
An Elite style game or maybe a rehash of Dark side something like, Imagine Star glider or Carrier command as a Plus game
Fued in 3d?

Maybe Doom
I'm not sure how the plus could enhance these games...?

Yes there is a bigger palette, but in the end both of these would be just like recoloured versions of the cpc.

Again, a doom style game is unlikely to be faster on the plus (but proove me wrong), but it would be more colourful.

plus is better for colours, scrolling and nice sprites. the dma sound helps for interrupts and to make sampled sound.



My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

arnoldemu

I have just tested this on my 464 plus:

There is no keyboard clash between the joysticks and the keyboard. There is also no clash between the joysticks themselves.
This means 2 players can use joysticks OR one on keyboard and another on joystick and there will not be any problems. This is what I expected to be honest and it's good news.

What I did not test is daisy chaining of joystick 2 on joystick 1. Docs say it's possible, no idea if there will be clash or not, I assume not.


I also tested the AJ-5 analogue joystick. Fire buttons are mapped to digital joystick 0 fire buttons as I expected. X/Y values on "channels 0 and 1". One suprising thing is that fire I on the joystick is fire 2 on the cpc. And fire II on the joystick is fire 1.

I wish the cpc didn't have the clash between joystick and keyboard, would have made playing 2 player gauntlet a bit more easy ;)
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

TFM

Quote from: arnoldemu on 19:34, 31 August 13
I also tested the AJ-5 analogue joystick. Fire buttons are mapped to digital joystick 0 fire buttons as I expected. X/Y values on "channels 0 and 1". One suprising thing is that fire I on the joystick is fire 2 on the cpc. And fire II on the joystick is fire 1.


Well, I only have a single cheap joystick which I use for my 6128 Plus's Analogue port. Fire 1 is Fire 1, and 2 is 2. Maybe this is rather Joystick-dependent.

TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

arnoldemu

ok.

I tried something else:

I wanted to try and repeat the same sprite across the screen. If the sprite is set to x4 mag, then it takes 64 mode 2 pixels, which is the same as 4us. I have just enough time to set the x coordinate.


;; This example shows a CPC+ hardware sprite.
;;
;; This example is designed for CPC+ only and will
;; not work on CPC or KC Compact.
;;
;;
;; This example will compile with the MAXAM assembler
;; or the built-in assembler of WinAPE32.

;; 1 mode 1 char is 1us.
;; which is 2 bytes. and 8 pixels
;; 2 mode 1 chars is 2us, 4 bytes and 16 pixels.



;; NOTE - For this example to work, the code must not
;; be in the range &4000-&7fff inclusive. The ASIC registers
;; are paged into this range, and the code would not be
;; visible to the CPU if it was also in this range.
org &8000
scr_set_mode equ &bc0e
txt_output equ &bb5a

start:
;;--------------------------------------------------
;; STEP 1 - Unlock CPC+ additional features
;; unlock asic to gain access to asic registers


;; set the screen mode
ld a,1
call scr_set_mode

ld d,'A'
ld b,24
l2:
ld c,40
l1:
ld a,d
call txt_output
dec c
jr nz,l1
inc d
dec b
jr nz,l2

di
ld b,&bc
ld hl,sequence
ld e,17
seq:
ld a,(hl)
out (c),a
inc hl
dec e
jr nz,seq
ei

;;--------------------------------------------------
;; STEP 2 - Setup sprite pixel data
;;
;; The ASIC has internal "RAM" used to store the sprite pixel
;; data. If you want to change the pixel data for a sprite
;; then you need to copy new data into the internal "RAM".

;; page-in asic registers to &4000-&7fff
ld bc,&7fb8
out (c),c

;; stored sprite pixel data
ld hl,sprite_pixel_data

;; address of sprite 0 pixel data
;; sprite 0 pixel data is in the range &4000-&4100
ld de,&4000

;; length of pixel data for a single sprite (16x16 = 256)
ld bc,&100
ldir

;; page-out asic registers
ld bc,&7fa0
out (c),c

;;--------------------------------------------------
;; STEP 3 - Setup sprite palette
;;
;; The sprites use a single 15 entry sprite palette.
;; pen 0 is ALWAYS transparent.
;;
;; The sprite palette is different to the screen palette.

;; page-in asic registers to &4000-&7fff
ld bc,&7fb8
out (c),c

;; copy colours into ASIC sprite palette registers
ld hl,sprite_colours
ld de,&6422
ld bc,15*2
ldir

;; page-out asic registers
ld bc,&7fa0
out (c),c

;;--------------------------------------------------
;; STEP 4 - Setup sprite properties
;;
;; Each sprite has properties which define the x,y coordinates 
;; and x,y magnification.

;; page-in asic registers to &4000-&7fff
ld bc,&7fb8
out (c),c


;; set x coordinate for sprite 0
ld hl,100
ld (&6000),hl

;; set y coordinate for sprite 0
ld hl,100
ld (&6002),hl

;; mag
ld a,%1101
ld (&6004),a

;; line before
ld a,99
ld (&6800),a

di
ld hl,&c9fb
ld (&0038),hl
ei
ld bc,&7f10
out (c),c
ld bc,&7f54
out (c),c
loop:
;; about 14 cycles to get to the correct point
;; setup for X
ld hl,&6000        ;; [3]
ld de,&6001        ;; [3]
ld a,&1            ;; [2]
ld c,&0+5            ;; [2]
                ;; = [10]
halt            ;; after hsync

;; 8-3 gives gap of about 6 pixels (sprite starts at pixel 0) except where I am forced to write both bytes
;; 8-2 gives gap of about 4 pixels (sprite starts at pixel 4 though) except where I am forced to write both bytes 
;; adding on 5 gives a small gap between
defs 8-2

rept 16
ld (hl),0+5
nop
ld (hl),64+5
nop
ld (hl),128+5
nop
ld (hl),192+5
nop
ld (hl),c
ld (de),a ;; &100
ld (hl),64+5
nop
ld (hl),128+5
nop
ld (hl),192+5
inc a
ld (hl),c
ld (de),a ;; &200
ld (hl),64+5
dec a
dec a
ld (de),a
inc a
defs 24-1-2-1
endm
jp loop
;;--------------------------------------------------
ret


;;--------------------------------------------------
;; - there is two bytes per colour.
;; - these are stored in a form that can be written direct 
;; to the CPC+ colour palette registers (i.e. xGRB)
;; - pen 0 is always transparent and doesn't have a entry
;; in the CPC+ palette

sprite_colours:
defw &0111            ;; colour for sprite pen 1
defw &0222            ;; colour for sprite pen 2
defw &0333            ;; colour for sprite pen 3
defw &0444            ;; colour for sprite pen 4
defw &0555            ;; colour for sprite pen 5
defw &0666            ;; colour for sprite pen 6
defw &0777            ;; colour for sprite pen 7
defw &0888            ;; colour for sprite pen 8
defw &0999            ;; colour for sprite pen 9
defw &0aaa            ;; colour for sprite pen 10
defw &0bbb            ;; colour for sprite pen 11
defw &0ccc            ;; colour for sprite pen 12
defw &0ddd            ;; colour for sprite pen 13
defw &0eee            ;; colour for sprite pen 14
defw &0fff            ;; colour for sprite pen 15

;;---------------------------------------------
;; - there is one pixel per byte (bits 3..0 of each byte define the palette index for this pixel)
;; - these bytes are stored in a form that can be written direct to the ASIC
;; sprite pixel data
sprite_pixel_data:
defb &01,&01,&01,&01,&01,&01,&01,&01,&01,&01,&01,&01,&01,&01,&01,&01        ;; line 0
defb &02,&02,&02,&02,&02,&02,&02,&02,&02,&02,&02,&02,&02,&02,&02,&02        ;; line 1
defb &03,&03,&03,&03,&03,&03,&03,&03,&03,&03,&03,&03,&03,&03,&03,&03        ;; line 2
defb &04,&04,&04,&04,&04,&04,&04,&04,&04,&04,&04,&04,&04,&04,&04,&04        ;; line 3
defb &05,&05,&05,&05,&05,&05,&05,&05,&05,&05,&05,&05,&05,&05,&05,&05        ;; line 4
defb &06,&06,&06,&06,&06,&06,&06,&06,&06,&06,&06,&06,&06,&06,&06,&06        ;; line 5
defb &07,&07,&07,&07,&07,&07,&07,&07,&07,&07,&07,&07,&07,&07,&07,&07        ;; line 6
defb &08,&08,&08,&08,&08,&08,&08,&08,&08,&08,&08,&08,&08,&08,&08,&08        ;; line 7
defb &09,&09,&09,&09,&09,&09,&09,&09,&09,&09,&09,&09,&09,&09,&09,&09        ;; line 8
defb &0a,&0a,&0a,&0a,&0a,&0a,&0a,&0a,&0a,&0a,&0a,&0a,&0a,&0a,&0a,&0a        ;; line 9
defb &0b,&0b,&0b,&0b,&0b,&0b,&0b,&0b,&0b,&0b,&0b,&0b,&0b,&0b,&0b,&0b        ;; line 10
defb &0c,&0c,&0c,&0c,&0c,&0c,&0c,&0c,&0c,&0c,&0c,&0c,&0c,&0c,&0c,&0c        ;; line 11
defb &0d,&0d,&0d,&0d,&0d,&0d,&0d,&0d,&0d,&0d,&0d,&0d,&0d,&0d,&0d,&0d        ;; line 12
defb &0e,&0e,&0e,&0e,&0e,&0e,&0e,&0f,&0e,&0e,&0e,&0e,&0e,&0e,&0e,&0e        ;; line 13
defb &0f,&0f,&0f,&0f,&0f,&0f,&0f,&0f,&0f,&0f,&0f,&0f,&0f,&0f,&0f,&0f        ;; line 14
defb &01,&01,&01,&01,&01,&01,&01,&01,&01,&01,&01,&01,&01,&01,&01,&01        ;; line 15


;;----------------------------------------------------------
;; this is the sequence to unlock the ASIC extra features
sequence:
defb &ff,&00,&ff,&77,&b3,&51,&a8,&d4,&62,&39,&9c,&46,&2b,&15,&8a,&cd,&ee
end start


So, I can't get the sprites to join up. there is always a gap, especially where I set the coord to &100 and &200. The official documents do state that the sprite is removed from the display for the duration of the access and I can see it happening here. I am testing on a 464 plus.

Where &100 and &200 are written there is the biggest gap, but for the others the gap is smaller. Interestingly, if I shift the sprite coords a little I can reduce the gap (must be down to when the asic reads the sprite coordinates), but it's around 4 mode 2 pixels still.

Of course this method requires I re-write the x coordinate across the screen and for every line the sprite is on. So it uses a lot of cpu time.

I have ideas for putting different sprites side by side using a similar method; this should work because I can write the x coordinate for another sprite while I am displaying another sprite. The idea being I have the same graphics in 2 sprites, so 2 sets of sprites, then I can carefully repeat them - sprites will be mode 0 resolution however because I can't get the code quicker for mode 1 sprites.

May work out well for a puzzle game where you have circles of different colours that can be side by side.

Sad it didn't work as I hoped; I hoped there was some time in which I could write the x coordinate and the asic would continue to draw from the current sprite, then it would re-read the x coordinate a bit later and repeat it. Seems it re-reads it more often than I expected.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

redbox

Quote from: arnoldemu on 22:10, 31 August 13
Sad it didn't work as I hoped; I hoped there was some time in which I could write the x coordinate and the asic would continue to draw from the current sprite, then it would re-read the x coordinate a bit later and repeat it. Seems it re-reads it more often than I expected.

I have been doing a lot of work trying to multiplex Plus sprites and found the same as you did.

However, if you work as if you were using a single screen (i.e. not double buffered) and avoid the screen draw area then you can use this CPU time to alter the X and Y registers easily.  If you combine this with a buffer and algorithm (which is calculated every frame) to work out which where you want to draw the sprites you can 'repeat' a lot of sprites quite easily - but of course it's definitely suited to a certain 'type' of game and the timing has to be exact ;)

MacDeath

Wonderboy 2 & 3 (see sega versions) could be sweet games...










No need for complicated scrollings, simple sprites, Mode0, and so on...


Those game can contain a good dose of JRPG actually... stuff, buffs, powers and so on.
And have a MarioWorld-like map and so on.


Yet still be decent platformers.




Otherwise, a mix between Black Tiger and Wonderboy 2&3 (= more serious grit gritier grimdark and so on)

arnoldemu

@MacDeath: Yes that seems more possible.

For the moment, people should work with the limits, and either limit themselves to 16 sprites as most of the current plus games do OR mix hardware sprites and software sprites.

So.. when are the first new games comming? ;)
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

tastefulmrship

#57
I've always wanted to see Amiga classics on CPC+ (CarVup, Pardroid90, 9-Lives, etc) but this game is a must (if you want to convert rather than originate). And it's not as if I am about 65% into converting the music to CPC or anything (cough, cough), it's just that I think it would transfer to CPC (both normal & plus) rather well... and if we have the intro, mid-theme sections, outro and title/highscore then it could be the total conversion package... stuck on a CPC+ cartridge ready for sale/download. (It's not as if Si-nog-sis could sue for the conversion anymore!)


And again, I'm not doing any music from this game... despite there being a link to the .mod files at the bottom of that page! ^_^ Hehe... cough!

Axelay

Quote from: tastefulmrship on 11:34, 03 September 13
It's not as if Si-nog-sis could sue for the conversion anymore!



Not sure I'm convinced that would be the case with Sony only just digging Shadow of the Beast out of the archives.  ;)

Trebmint

Id love to do a few more plus games, and I've got a lot of code and graphics that are waiting. But until a solution is found for the cartridge issue it seems pointless.


Isn't there a solution where a standard cart is modified so that you can plug n play roms? Seems like an obvious way round it. Nobody is gonna wanna put the thousands it would take into getting a case modelled and then you have the problem of the acid.

steve

Bluesbrothers is getting the cases made, the acid has been cracked, it just needs to be put into a cpld or real acid chips can still be bought.

redbox

Quote from: Trebmint on 16:17, 03 September 13
Isn't there a solution where a standard cart is modified so that you can plug n play roms? Seems like an obvious way round it. Nobody is gonna wanna put the thousands it would take into getting a case modelled and then you have the problem of the acid.

You could make a DIY Cartridge.

Or if you don't want to make a PCB, then cut the ROM from an existing cartridge and put a socket on and then insert your own EPROMs at will.

redbox

Quote from: tastefulmrship on 11:34, 03 September 13
And again, I'm not doing any music from this game... despite there being a link to the .mod files at the bottom of that page! ^_^ Hehe... cough!

Are you converting them to AY chiptunes or playing the MODs on the CPC...?

tastefulmrship

Quote from: redbox on 21:16, 03 September 13
Are you converting them to AY chiptunes or playing the MODs on the CPC...?
As always, I'm converting them to AY, but most of the tunes are 3-channel anyway, so there's no reason why a "CPC+ conversion" couldn't play the .mods direct.

I keep meaning to find time to experiment with your new Arkos player (for a version of Heatbeat's Believe) and I have my first weekend off work since Easter this week, so I might give it a go. My original problem with 8bit samples on CPC was finding the correct frequency; all my "voice" samples were just too slow. (I'll continue this discussion in that thread)

TFM

#64
Ok, can we get back to topic?[nb]New Plus Series Game a Proposal[/nb]
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

redbox

Well it is on topic - I was asking about the MODs because if tastefulmrship wants I can help convert some samples (drums etc) to DMA for use on the Plus.

Sorry I didn't get around to answering quickly enough for you.

TFM

What this guy[nb]tast full ship or so[/nb] can:
- use black humor
- Like posts with black humor
- bitch if one has an other opinion
- bitch at programmers


What this guy doesn't can:
- Programming on a Plus


:laugh:
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

arnoldemu

Is there a version of Prodatron's Protracker for Plus?

Or a similar 3 player full sample tracker.

I believe Weee! wrote one and released a demo, but I never saw the tracker :(
Did BSC write one to make the music for Prehistorik 2?

Would be good to get that released.

Even previews of these trackers would be good to see, the playback routine alone is worth it, even if the data could be made in another tracker.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

GOB

Quote from: arnoldemu on 09:27, 05 September 13
Is there a version of Prodatron's Protracker for Plus?

Or a similar 3 player full sample tracker.

I believe Weee! wrote one and released a demo, but I never saw the tracker :(
Did BSC write one to make the music for Prehistorik 2?

Would be good to get that released.

Even previews of these trackers would be good to see, the playback routine alone is worth it, even if the data could be made in another tracker.


No there is nothink on Plus for making tunes...
In Prehistorik 2 it's Weee, not BSC who make the first tune. It's is own tracker.
So nothink for making tunes on CPC Plus...
You can also see all Semilanceata demos:
http://www.cpc-power.com/index.php?page=detail&num=7958
http://www.cpc-power.com/index.php?page=detail&num=7935
http://www.cpc-power.com/index.php?page=detail&num=8553


And Ukonx demo:
http://www.cpc-power.com/index.php?page=detail&num=8072


Grim and power make here own convertisseur of .MOD
So if you want a MOD tracker for CPC Plus, you must make your own, because nobody seams to want making it for others...


Sorry for my english also ^^

redbox

I think that a pure MOD tracker/player for the Plus isn't the best solution as the samples can't be played at different pitches (or you have to store different samples for all the pitches).

Much better to have 2/3 AY channels and include 1 DMA channel like the ST I think.

But of course if you are converting Amiga MODs you could redo the tune in AY and then convert the drum samples etc to DMA format.  Or the best solution might be rip the AY tunes from the ST and then use the Amiga drum samples as they are usually a higher quality to start with (most ST digidrums are 11025hz or lower).

arnoldemu

Quote from: redbox on 10:18, 05 September 13
I think that a pure MOD tracker/player for the Plus isn't the best solution as the samples can't be played at different pitches (or you have to store different samples for all the pitches).
In a normal MOD player you have to mix the channels to play them.

I assume a MOD player on Plus, does this and writes the data into a buffer which the DMA reads at a
fixed rate.

So the mixing routine does all the work and outputs a mixed 8Khz/15Khz sound that the DMA plays at that rate.



Quote from: redbox on 10:18, 05 September 13
Much better to have 2/3 AY channels and include 1 DMA channel like the ST I think.

But of course if you are converting Amiga MODs you could redo the tune in AY and then convert the drum samples etc to DMA format.  Or the best solution might be rip the AY tunes from the ST and then use the Amiga drum samples as they are usually a higher quality to start with (most ST digidrums are 11025hz or lower).
Having 2/3 AY and 1 DMA drums is nice yes, but sometimes nice to have full sampled sound.

Also having 2/3 AY and 1 SID-Voice is nice too.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

GOB

#71
As say Arnoldemu, Mod player writes data into a buffer.
It take some CPU because we must calculate sample frequency and write it to the good frequency...
It's the same than in an old CPC...
Adventage of the CPC+ is to play this sample that take 0 CPU with the DMA.


But for my opinion, playing sample have not a good result because of the rate.
I think it's more preferable to make SID voice or effect like this.


You can ear Sid voice on some of my production (player by Offset)for exemple. The result is good and my ears don't bleed like with sample :)


Sid on:
http://www.cpc-power.com/index.php?page=detail&num=9124
http://www.cpc-power.com/index.php?page=detail&num=7408


I have some other idea to make tunes on cpc+ with good result, and maybe i'll make a tracker some day...

McKlain

Sid voices are the best way to make a good lead sound on the AY. I miss them on my cpc songs...

ivarf

Quote from: Trebmint on 16:17, 03 September 13
Id love to do a few more plus games, and I've got a lot of code and graphics that are waiting. But until a solution is found for the cartridge issue it seems pointless.
3D-printers will soon do this for everyone - if we can make drawings for the cases

Sykobee (Briggsy)

Quote from: ivarf on 15:02, 06 September 13
3D-printers will soon do this for everyone - if we can make drawings for the cases


I think this was relating to the ACID chip than the casing - although you make a very good point about that.


But hopefully it's cracked as the comment above says and can be implemented on a cheap FPGA/CPLD/thing.

Powered by SMFPacks Menu Editor Mod