Thinking about trying out CGD before I try out PGD

[Cheez26]

So, I found this in the database and it seems fascinating somewhat. It also has a manual in PDF, which I've been reading carefully and it does seem solid documentation.

What do you think? Is it usable enough for a beginner like me?

[ketmar]

may i give you a small advice based on my own expirience? stop thinking, start doing!

you may evaluate various tools 'till the sun burns out, but it won't help you to create a game. just choose the tool which works, and try to create something simple with it. do not aim at anything big first: create something simple, so you could learn the tool and its limitatinons. then design your game around those limitations, and implement it.

and don't be discouraged if your several first games wouldn't be of stellar quality. there is nothing to be ashamed of. you will learn a lot on your way, you will be better prepared to try other tools, and you will learn the machine and the whole process of creation software for it better.

nobody'll better tell you if this or that tool is "better suited" for you than yourself. that's something only you can do, by trying to use them. maybe you'll find that all tools are not well-suited for your ideas, and then you'll learn Z80 asm, and write your own game engine, best suited to your game. there's nothing very complicated there too. ;-)

[ParadigmShifter]

Yeah exactly that.

It's super easy to write an 8x8 draw a sprite aligned to a character cell which is what that engine seems to be doing. Also the collision detection is easy as well!

You can get an 8x8 sprite moving under keyboard control easily and it will be so fast you need to either slow it down or add more game to make it run slower

That engine seems to have a background layer (probs full screen so 768 bytes) and only erases sprites (= put the sprite that was in the background layer back on the screen) and redraws them in a new position. That's simple.

Game logic can be a bit gnarly in ASM until you get used to it (especially nested if/else stuff and so on) but the only way to learn how to do that is to try, make mistakes and ask for assistance, how we all learned (maybe not the asking for assistance part, it's much easier now).

Code to draw an 8x8 sprite aligned to a character cell. EDIT: If you only erase cell contents and don't want to logical OR them to the screen you can speed this up too by removing all the OR (HL) instructions. This function should really be called sprite8x8aOR since it does not overwrite existing pixels.

Code: Select all

; B: row (in character cells, so [0-23])
; C: column, 0-31
; DE: 8 rows 8x1 sprite data (8 byte aligned)
sprite8x8a:
	ld a, b
	add b ; A = B*2
	ld h, tbl_rows/256 ; high byte of screen address lookup table. Aligned 256 so low byte will be just row*2
	ld l, a ; index into table 
	ld a, (hl) ; low byte of screen address
	inc l ; point HL to high byte of screen address
	ld h, (hl) ; read high byte of screen address
	add c ; add on column to low byte of screen address
	ld l, a ; and write it back. HL now holds correct screen address
	; so we now know the address...
; HL: screen address
; DE: 8 rows 8x1 sprite data (8 byte aligned)
sprite8x8aKnowAddr:
	IF UNROLL_Sprite8x8a
		REPT 7
			ld a, (de)
			inc e ; ok because gfx data is 8 byte aligned

			or (hl)

			ld (hl), a
			inc h ; next row of pixels down
		ENDR
	ELSE
		ld b, 7 ; draw 7 rows and increment gfx data pointer, screen row
.loop
		ld a, (de)
		inc e ; ok because gfx data is 8 byte aligned

		or (hl)

		ld (hl), a
		inc h ; next row of pixels down
		djnz .loop
	ENDIF

	; last row, don't need to increment gfx data pointer or screen row
	ld a, (de)

	or (hl)

	ld (hl), a
	ret

You probs want UNROLL_Sprite8x8a EQU 1 which unrolls the lop so it is faster but uses more memory for the code. UNROLL_Sprite8x8a EQU 0 does not unroll the loop saving a bit of memory. You have to EQU it to either 0 or 1 though otherwise it will give you an error.

You'll also want this scary macro and a table which needs to be 256 byte aligned (otherwise you have to do a lot of copy and pasting and need to know about the speccy screen layout... not recommended at first)

Code: Select all

SCRBASE EQU #4000 ; screen address 

	MACRO DWXYTOSCRADDR _x_, _y_
	dw SCRBASE + (((_y_&#7)|((_y_&#C0)>>3))<<8)|((_x_&#1F)|((_y_&#38)<<2))
	ENDM

	ALIGN 256
tbl_rows
	REPT 24, row
	DWXYTOSCRADDR 0, row*8
	ENDR

If your assembler does not support indexed REPT you can replace this

Code: Select all

tbl_rows
	REPT 24, row
	DWXYTOSCRADDR 0, row*8
	ENDR

with this

Code: Select all

tbl_rows
	DWXYTOSCRADDR 0, 0*8
	DWXYTOSCRADDR 0, 1*8
	DWXYTOSCRADDR 0, 2*8
	DWXYTOSCRADDR 0, 3*8
	DWXYTOSCRADDR 0, 4*8
	DWXYTOSCRADDR 0, 5*8
	DWXYTOSCRADDR 0, 6*8
	DWXYTOSCRADDR 0, 7*8
	DWXYTOSCRADDR 0, 8*8
	DWXYTOSCRADDR 0, 9*8
	DWXYTOSCRADDR 0, 10*8
	DWXYTOSCRADDR 0, 11*8
	DWXYTOSCRADDR 0, 12*8
	DWXYTOSCRADDR 0, 13*8
	DWXYTOSCRADDR 0, 14*8
	DWXYTOSCRADDR 0, 15*8
	DWXYTOSCRADDR 0, 16*8
	DWXYTOSCRADDR 0, 17*8
	DWXYTOSCRADDR 0, 18*8
	DWXYTOSCRADDR 0, 19*8
	DWXYTOSCRADDR 0, 20*8
	DWXYTOSCRADDR 0, 21*8
	DWXYTOSCRADDR 0, 22*8
	DWXYTOSCRADDR 0, 23*8

You also need to align your graphics data to an address that is a multiple of 8 so that the 8 bit maths the routine uses does not overflow.

To erase a sprite you can define a tile that is 8 bytes of 0... faster methods exist for doing that though (write another function which just writes 0 instead of graphics data to the screen). EDIT: If you don't remove the OR (HL) instructions you can't use it to erase anything on screen though so if you only want to overwrite what was in an 8x8 cell before take those out. Otherwise you need to write a proper erase function (which is also easy).

Erase function:

Code: Select all

; B: row (in character cells, so [0-23])
; C: column
erase8x8a:
	ld a, b
	add b ; A = B*2
	ld h, tbl_rows/256 ; high byte of screen address lookup table. Aligned 256 so low byte will be just row*2
	ld l, a ; index into table 
	ld a, (hl) ; low byte of screen address
	inc l ; point HL to high byte of screen address
	ld h, (hl) ; read high byte of screen address
	add c ; add on column to low byte of screen address
	ld l, a ; and write it back. HL now holds correct screen address
	; so we now know the address...
; HL: screen address
erase8x8aKnowAddr:
	xor a ; set A = 0

	REPT 7
		ld (hl), a
		inc h ; next row of pixels down
	ENDR

	ld (hl), a
	ret

[PeterJ]

@Cheez26,

I'm with @ketmar on this. You can try all the tools in the world, but that won't move you forward.

I know BASIC is frowned upon by many, but the original ZX Spectrum Manual is excellent. Work your way through it, and that will help you understand the machine. Write some simple games and get your hands dirty. We are all happy to help. You could even enter the annual Crap Games contest.

Also take a look at some of the type-ins games in the archives. Look for Sinclair User and Sinclair Programs. Rip the code apart..

Then maybe give Boriel a go. That will give you the speed you need as it's a compiler. Convert some slow BASIC games from above.

What I'm trying to say is that these games creators are great, but it's good to have an understanding of the machine, so you know why these creators do what they do.

You can then start thinking about assembly language (that's the stuff that @ParadigmShifter so eloquently posted above). That codes a bit advanced for me, but I see generally what's it's doing. IMHO the worst thing you can do is just use chunks of cider without having a clue what they do. There are loads of people here who can help you. There are also loads of great threads in the programming section.

Once you are at this stage (not before) then also look at C and Forth. @dfzx has created an excellent C tutorial, and @ketmar can help with Forth.

[R-Tape]

What do you think? Is it usable enough for a beginner like me?

As the author of C.G.D, I can say that it's entirely suitable for beginners and upwards. Everything you need to know should be in the manual and IMO the designer itself is intuitive and fun to use. It was nearly called the Crap Games Designer, but I opted for Classic because it can be used to make half-decent games with an oldschool flavour.

It depends what you want to achieve. If you want to use a tool and want high quality results quickly - go for MPAGD or one of its derivatives.

you may evaluate various tools 'till the sun burns out

But you can still make games even after that.

[Cheez26]

It depends what you want to achieve. If you want to use a tool and want high quality results quickly - go for MPAGD or one of its derivatives.

Yeah, maybe I should use one of the MPAGD derivatives instead; however, if all else fails, I will use Boriel BASIC for making a more custom experience. Maybe even some Z80 ASM when I need an in-line thing

[hikoki]

Do you like Roguelikes? that would be original for a MPAGD
I can suggest a game to be ported to the Speccy
Secret tip : you can open tap with MPAGD just for educational purposes

By the way, Crabby is the masterpiece made with CGD. I have sources if you are interested in

[ParadigmShifter]

My code might not work on all assemblers thinking about it

Code: Select all

tbl_rows
	DWXYTOSCRADDR 0, 0*8
	DWXYTOSCRADDR 0, 1*8
	DWXYTOSCRADDR 0, 2*8
	DWXYTOSCRADDR 0, 3*8
	DWXYTOSCRADDR 0, 4*8
	DWXYTOSCRADDR 0, 5*8
	DWXYTOSCRADDR 0, 6*8
	DWXYTOSCRADDR 0, 7*8
	DWXYTOSCRADDR 0, 8*8
	DWXYTOSCRADDR 0, 9*8
	DWXYTOSCRADDR 0, 10*8
	DWXYTOSCRADDR 0, 11*8
	DWXYTOSCRADDR 0, 12*8
	DWXYTOSCRADDR 0, 13*8
	DWXYTOSCRADDR 0, 14*8
	DWXYTOSCRADDR 0, 15*8
	DWXYTOSCRADDR 0, 16*8
	DWXYTOSCRADDR 0, 17*8
	DWXYTOSCRADDR 0, 18*8
	DWXYTOSCRADDR 0, 19*8
	DWXYTOSCRADDR 0, 20*8
	DWXYTOSCRADDR 0, 21*8
	DWXYTOSCRADDR 0, 22*8
	DWXYTOSCRADDR 0, 23*8

It may need brackets around the second argument depending on how the assembler deals with macro arguments, if that doesn't work this should (and note not all assemblers use the same macro format)

I use sjasmplus so the REPT 24, row thing works really well for removing copy and paste of simple tables like that.

Code: Select all

tbl_rows
	DWXYTOSCRADDR 0, (0*8)
	; ... snip
	DWXYTOSCRADDR 0, (23*8)

That should work (if it doesn't you may have to put extra brackets in the macro around the _x_ and _y_ dummy variables).

I don't know what's advanced about the code I posted the macro is a bit cryptic but it's better than typing a load of hex numbers for the screen rows like so

Code: Select all

tbl_rows	dw #4000, #4020, #4040, #4060, #4080, #40A0, #40C0, #40E0
				dw #4800, #4820, #4840, #4860, #4880, #48A0, #48C0, #48E0
				dw #5000, #5020, #5040, #5060, #5080, #50A0, #50C0, #50E0

which is what the macro versions should expand to.

I did use a bit of conditional assembly to control whether the loop is unrolled or not.

Beginning of the functions looks up the row address from tbl_rows and adds on the column, which is faster than doing the maths at runtime to work out the same value as in the table.

Then the rest of the function should be pretty obvious I think and it's quite well commented (apart from I should have mentioned you should comment out OR (HL) to do a destructive write to cell contents rather than OR with existing cell contents I suppose).

[Cheez26]

@R-Tape A couple questions for the foreseeable future:

1. Will there be a 128k upgrade that can load AY tunes as well as make use of the Kempston mouse for easier and quicker development of games with this kinda tool?
2. Will there even be more software like this from you in the future? I will say that it does look pretty emulator friendly for what it was designed for.

[R-Tape]

1 - No I've no plans to do any upgrades to CGD. AY can be hacked in afterwards though, as gasman for Yerz on The Deadly Labyrinth of Lord Xyrx.

2 - I'll never say never, but highly unlikely (thanks tho).

[Cheez26]

@R-Tape Late reply, but I think it might be too complicated to just hack in the code necessary to run AY music and sound.
Anyhow, thanks for answering my questions. I do hope you find the time to make new software for the Speccy.

[Einar Saukas]

So, I found this in the database and it seems fascinating somewhat.

Then go for it.

Don't overcomplicate this. Aiming too high for your first game is an effective way to ensure you will never release anything.