Fast-RPL version 0.6

[necro]

it would be neat if there was sprite scaling and stretching (so you could make games like gemeni or doom) and tile mapping built in

[kuda]

take a look at mario sample ! There is a tile mapping routine built in !

[necro]

so...will there be stretching/scaling routine? (are you considering it at all) and as far as no grey-scale ...any chance it will change?

[kuda]

well, in fact, i'm not consediring programming myself this kind of routine, but, if people want them, I can adapt existant routine...
But fastRPL is not as fast as ASM. si even if greyscale are implemented in ASM, it wont let much speed to the interpretor...
But it may be sufisant for RPG games like in basic... and maybe for some others...

Stretching, is also a good idea, but it may be slow... and a DOOMlike also require deformation routine (when you dont look a wall in front of it)...

[DJ_O]

Ouch, doom-like in non ASM , maybe Raycasting should be used for 3D RPGs only when the game is not in asm But once Jim e release RGP you could use it as the grayscael routine but the prgmer should be given up the option of having grayscale or not

[kuda]

I agree :p

[That_One_Guy]

oi, umm...i cant get any of this stuff to work. I can get into the editor, but nothing i do works, hell, not even the first math example on the tutorial, nor any of the games

[MetalHead25]

can someone translate french? those tutorials on his website look nice

[kuda]

if the first math sample doesn't work, you may need to put a "Stop" before the end of the file, else, the interpretor read garbarge...
Tutorial in french, when i'll have the time :p

[necro]

well, kuda, any progress?

[Comikal]

About the libs, I asked kuda why they werent working, and he told me that libs had to be specifically desgined for RPL. He then sent me a sample of an RPL lib:

Code: Select all

org 0    						; permet l'adressage relaif

db $FE								; entete spécifique des libraires pour fastRPL
db $BB


db 2									; Nombre de fonction a ajouter

db $C1								; N° du token appelant la fonction
dw linkReceive				;adresse relative dans AAAAAAAA de la fonction
db "L-Get",0,0,0			; nom de la fonction dans l'editeur

db $C2
dw linkSend
db "L-Send",0,0


;receiveByte		=40A1h
;sendByte		=409Eh

receiveByte		=4f03h
sendByte		=4ee5h
#define bcall(xxxx)	rst 28h \ .dw xxxx

linkReceive:

	pop 	bc
linkReceive_wait:
	di
	in	a,(2)
	rla
	jr	nc,TI83Plus
TI83PlusSE:
	in	a,(9)
	and	18h
	jr	chkReceive
TI83Plus:
	in	a,(0)
	and	03h
	cp	03h
chkReceive:
	jr 	nz,chkReceive_Ok
	dec 	bc
	ld 	a,b
	or 	c
	jr 	nz,linkReceive_wait
chkReceive_fail:
	ld hl,0
	push hl
	push hl
	jp $9D97  ;; (progstart+2)	;retour (indirect a readloop, indirect car si FastRPL est modifié, les libvraies doinvent encores fonctionner meme si on déplace readloop... donc en fait, a cet adresse il y aura dans toutes les version un saut vers readloop)	
chkReceive_Ok:
	push	bc
	bcall(receiveByte)
	cp	%10100101
	jr 	nz,chkReceive_fail
	bcall(receiveByte)
	push	af
	bcall(receiveByte)
	pop	bc
	ld	c,a
	pop	hl
	push 	bc
	push 	hl
	jp $9D97  ;; (progstart+2)	;retour (indirect a readloop, indirect car si FastRPL est modifié, les libvraies doinvent encores fonctionner meme si on déplace readloop... donc en fait, a cet adresse il y aura dans toutes les version un saut vers readloop)	


linkSend:
	ld 	a,%10100101
	bcall(sendByte)
	pop 	af
	push 	af
	bcall(sendByte)
	pop 	hl
	ld 	a,l
	bcall(sendByte)
	jp $9D97  ;; (progstart+2)	;retour (indirect a readloop, indirect car si FastRPL est modifié, les libvraies doinvent encores fonctionner meme si on déplace readloop... donc en fait, a cet adresse il y aura dans toutes les version un saut vers readloop)	

	
end
END

Unfortunately, I cannot speak,read,write nor translate french or understand ASM. Could someone please interpret this?

[kuda]

Well, libs are not working very fine, I dunno why but they work after a RAM clear, so I think their might be an uncompatibility with some apps...

I can explain the file if you want :p

Code: Select all

org 0  

; let you use relative address. As the lib isn't loaded to progstart ($9D95) you should only use jr (no jp or call) in your libs... but if you really need to know the current adress of a part of your code that can be useful, knowing that when one of your function is called, its address is in HL, so with soustraction and addition you may find evry adresse of your code...
(
add hl,desired_address-function_adresse
jp (hl)
)

Code: Select all

db $FE                   ; entete spécifique des libraires pour fastRPL 
db $BB 

Special header for fastRPL libs, in order no to load ASM or basic program as libraries...

Code: Select all

db 2                           ; Nombre de fonction a ajouter 

number of function to add

Code: Select all

db $C1                        ; N° du token appelant la fonction 

Number of the token

Code: Select all

dw linkReceive            ;adresse relative dans AAAAAAAA de la fonction 

Adress of the function ( relative thanks to .org 0)

Code: Select all

db "L-Get",0,0,0         ; nom de la fonction dans l'editeur 

Text of the token (must be 8 bytes )

Code: Select all

   jp $9D97  ;; 

return to the reading loop
(not ret because the stack is reserved for RPL, not for ASM... you may use it but don't mess it)

But some stuff might change with the next version !!! so you may write libs, but you'll have to change some stuff , like the return because I still dont know how to exec from ROM to RAM then from RAM to ROM...

The apps now take 3 pages...

Kuda