Can I try the editor somewhere and is there a documentation ? I wonder how much space a minimal fullscreen editor would take. 2.9 KB is quite a lot, considering line editor can take perhaps one third of space, I guess.ketmar wrote: ↑Wed Mar 27, 2024 4:49 pm i had to look at (and edit) the sample game. standard line editor sux, so i wrote the fullscreen one. and implemented 64 columns print driver for it.
the editor works in any mode, though (32, 42, 64). it has line yank/insert, and nice incremental search.screenshot
sadly, editor source cannot be made loadable on Speccy itself: it is using some headerless system words. i removed headers from some rarely used internal words to save some RAM (and the editor itself is mostly headerless too). but it is only 2.9KB, so i guess i can include it instead of the old line-oriented one.
Abersoft fig-Forth Recompiled
Re: Abersoft fig-Forth Recompiled
Proud owner of Didaktik M
Re: Abersoft fig-Forth Recompiled
latest demos in this topic are compiled with the editor. just type "LOADT 1 EDIT".
and it is not minimal, i added quite a number of features — because i am using this editor to edit blocks in the emulator. ;-)
there is no documentation yet, but pressing CS+SS will show some extended commands in the status line. there are more commands there, but the status line is too short. ;-)
as the editor is mostly in Forth (sans one or two code words added for speed), it will be possible to load it on ZX from block file later. with transient vocabularies system in place (still have to implement it) it won't take any program space at all. ;-)
p.s.: it is about 20 KB of Forth source, so ~3 KB is quite good, i believe. ;-)
Re: Abersoft fig-Forth Recompiled
i cached "NEXT" in IX. the code became slightly smaller, and slightly faster. not much, but why not? IX was used for user area pointer, but we don't have a lot of uservars anyway, so it was a waste of register.
i wonder if caching TOS in DE will do any good. but this will require rewriting of all primitives, and it would be hard to make it optional (the code will became a mess). i don't expect a huge speedup anyway, so i decided to not try it yet. at least not in this system.
also, i am too lazy to decompile "laser library" from White Lightning. i think it would be easier to write simple blitters myself — nobody really needs the whole "laser lib" anyway. it is nice to have, but i believe that "get-sprite" and "put-sprite" will be enough for practical purposes.
i definitely remember seeing laser basic disassemly, but my google-foo is not strong enough to find it. alas.
i wonder if caching TOS in DE will do any good. but this will require rewriting of all primitives, and it would be hard to make it optional (the code will became a mess). i don't expect a huge speedup anyway, so i decided to not try it yet. at least not in this system.
also, i am too lazy to decompile "laser library" from White Lightning. i think it would be easier to write simple blitters myself — nobody really needs the whole "laser lib" anyway. it is nice to have, but i believe that "get-sprite" and "put-sprite" will be enough for practical purposes.
i definitely remember seeing laser basic disassemly, but my google-foo is not strong enough to find it. alas.
Re: Abersoft fig-Forth Recompiled
wrote simple sprite blitter. currently only in overwrite mode, at char positions. tested on White Lightning sprites, lol. the code is not superfast (althroug it is using unrolled LDI loop per sprite line).
it would be easy to modify the blitter to allow arbitrary y coords (not restricted to chars), but whithout attributes, of course. it is also possible to save screen part in sprite format, and either blit it back, or use it as a sprite. lib size is ~400 bytes (this includes screen$ save/restore too). so no more stupid UDGs, we have Almost Real Sprites now! ;-)
i really have to port XTE2 to this! ;-)
of course, the blitters do no sprite clipping, but hey, it is better than nothing!
i prolly need to write a better sample game now. ;-)
it would be easy to modify the blitter to allow arbitrary y coords (not restricted to chars), but whithout attributes, of course. it is also possible to save screen part in sprite format, and either blit it back, or use it as a sprite. lib size is ~400 bytes (this includes screen$ save/restore too). so no more stupid UDGs, we have Almost Real Sprites now! ;-)
i really have to port XTE2 to this! ;-)
of course, the blitters do no sprite clipping, but hey, it is better than nothing!
i prolly need to write a better sample game now. ;-)
Re: Abersoft fig-Forth Recompiled
added (optional) OR/XOR/AND blitters too. with all blitters included library size is ~1KB.
Re: Abersoft fig-Forth Recompiled
creating flicker-free XOR sprites is surprisingly hard. i wonder how Jonathan Cauldwell did it in AGD. althrough AGD is not shifting sprites, i believe.
i created 16x16 blitter with shifting, so i can blit at any x pixel coord, but of course it flickers hard. HALT only helps with 2 sprites or so.
another idea was to simultaneously erase the old sprite and print the new one. now it flickers like there is a running tv static, lol. i mean, one horizontal sprite line. looks fun, but…
the problem is that with run-time shifting, i simply don't have enough time in interrupt handler to process any good number of sprites. and i don't want to remove shifting, this is a handy feature.
ok, another idea: let's waste 160 bytes per active sprite. store old and new sprite data, and precalced scr$ addresses there. this way interrupt handler will have to do a minimum amount of work: basically, read address, xor several bytes, repeat until there are no more updates.
problem: interrupt may trigger when we half-finished updating the buffer. prolly need some way to mark the sprite as "updating yet".
i still think that XOR sprites sux (sorry, Jonathan! ;-), but writing flicker-free XOR engine is surprisingly hard. much harder than doing masked sprites with double buffering. ;-)
and now for something completely different. i suddenly found a way to make my libraries with asm code loadable on ZX itself, and without any asm compiler! Forth code is ok, it doesn't use anything ZX cannot compile. and for asm, i can simply preprocess everything! i mean, i can output compiled machine code ("$76 C,", and so on), and then simply emit some Forth code to fix labels. my assembler tracks all labels anyway (for cross-reference files), so it's not a problem to write fixups.
this way we can have a base system, and add various bells and whistles (libraries) on ZX itself. yay. quite useless, but hey, this is something that could be done back then on ZX itself, and it is a sensible way to distribute libraries. so let's pretend that i am simply emulating something some software house did in 80s. at least you won't need any cross-compiler to build the system you like.
i created 16x16 blitter with shifting, so i can blit at any x pixel coord, but of course it flickers hard. HALT only helps with 2 sprites or so.
another idea was to simultaneously erase the old sprite and print the new one. now it flickers like there is a running tv static, lol. i mean, one horizontal sprite line. looks fun, but…
the problem is that with run-time shifting, i simply don't have enough time in interrupt handler to process any good number of sprites. and i don't want to remove shifting, this is a handy feature.
ok, another idea: let's waste 160 bytes per active sprite. store old and new sprite data, and precalced scr$ addresses there. this way interrupt handler will have to do a minimum amount of work: basically, read address, xor several bytes, repeat until there are no more updates.
problem: interrupt may trigger when we half-finished updating the buffer. prolly need some way to mark the sprite as "updating yet".
i still think that XOR sprites sux (sorry, Jonathan! ;-), but writing flicker-free XOR engine is surprisingly hard. much harder than doing masked sprites with double buffering. ;-)
and now for something completely different. i suddenly found a way to make my libraries with asm code loadable on ZX itself, and without any asm compiler! Forth code is ok, it doesn't use anything ZX cannot compile. and for asm, i can simply preprocess everything! i mean, i can output compiled machine code ("$76 C,", and so on), and then simply emit some Forth code to fix labels. my assembler tracks all labels anyway (for cross-reference files), so it's not a problem to write fixups.
this way we can have a base system, and add various bells and whistles (libraries) on ZX itself. yay. quite useless, but hey, this is something that could be done back then on ZX itself, and it is a sensible way to distribute libraries. so let's pretend that i am simply emulating something some software house did in 80s. at least you won't need any cross-compiler to build the system you like.
Re: Abersoft fig-Forth Recompiled
oh, i see. Jonathan did exactly what i thought of: simultaneous erasing and drawing after vblank. only AGD doesn't have run-time sprite shifting, so no need for any temp buffers. ok, i will prolly make two versions: with shifts, and without. so 3 sprite engines now, lol: White Lightning like, XOR16 with shifts, XOR16 without shifts.
and don't ask me why, please. i know that nobody will use this to write games. especially considering that the main system is in contended memory, and therefore is bloody slow. but it is fun to write!
and don't ask me why, please. i know that nobody will use this to write games. especially considering that the main system is in contended memory, and therefore is bloody slow. but it is fun to write!
Re: Abersoft fig-Forth Recompiled
There's always Machine Lightning, which presumably has similar capabilities. While the software is in the archives, the documentation appears to be lost at the moment
Re: Abersoft fig-Forth Recompiled
thank you! but it still doesn't have a source code (or i am unable to extract it). i mostly need the source to create relocatable code, and to allow selecting which part of the library should be compiled in.
sure, i can write it all myself, but… this is boring. ;-)
also, my sprite blitter is faster. ;-)
Re: Abersoft fig-Forth Recompiled
i implemented "prepare, then redraw in interrupt handler" engine for 16x16 sprites with run-time shifting… and will throw it away now. ;-) it doesn't worth the efforts. it requires 2KB for buffers, takes a lot of time to prepare buffers, and dog slow even with 13 sprites (this is as much as it can update in one interrupt).
using preshifted sprites will be much faster, and will not require any additional buffers. i mean, the code will prolly be able to update only about 8-9 sprites per interrupt, but without any extra time spent on preparations (so you don't have to share game logic time with housekeeping code).
using preshifted sprites will be much faster, and will not require any additional buffers. i mean, the code will prolly be able to update only about 8-9 sprites per interrupt, but without any extra time spent on preparations (so you don't have to share game logic time with housekeeping code).
-
ParadigmShifter
- Manic Miner
- Posts: 673
- Joined: Sat Sep 09, 2023 4:55 am
Re: Abersoft fig-Forth Recompiled
I wouldn't recommend drawing in the interrupt code myself. Unless there's no HALT of course.
I did say to someone the other week maybe do a backbuffer copy in the interrupt though (but you rightly pointed out a full screen backbuffer copy would be too slow even using the stack, so can only be done for backbuffer not too big). Then I backtracked and said don't draw in the ISR do it after the HALT since it's much easier.
When I did draw in the interrupt routine (first attempt at ASM coding ever) I was using a backbuffer but had a dirty list of which cells from the backbuffer needed copying to the screen (3 bytes per row, a bitfield of clean/dirty flag for each character cell that was dirty). Note I did not do the dirty buffer handling inside the ISR either I turned it into an #FF terminated list (well a size 64 array) I think, with a max size of 64 entries, and a flag for "we have more than 64 cells to update, just copy the entire backbuffer" - which was used for first drawing of each level). That turned out to be a pain to implement though and made my actual sprite drawing slower cos I had to update the dirty buffer). I used self modifying code to outside the ISR to signal that we are ready to draw i.e. I replaced the 0 operand in LD A, 0 here:
readytodraw: LD A, 0
OR A
RET Z
by doing
DI
LD (readytodraw+1), 1 ; obvs not really this, I had to LD A, 1 first and LD (readytodraw+1), A
EI
when I was done updating game logic etc. ISR routine would set it back to 0 at the end.
I would recommend preparing as much as possible AFTER drawing sprites for the next frame (e.g. do the shifting for the next frame into per sprite buffers if you have the space for that, you'd need 1 buffer per sprite then though, much more complicated if you have variable width sprites).
I did say to someone the other week maybe do a backbuffer copy in the interrupt though (but you rightly pointed out a full screen backbuffer copy would be too slow even using the stack, so can only be done for backbuffer not too big). Then I backtracked and said don't draw in the ISR do it after the HALT since it's much easier.
When I did draw in the interrupt routine (first attempt at ASM coding ever) I was using a backbuffer but had a dirty list of which cells from the backbuffer needed copying to the screen (3 bytes per row, a bitfield of clean/dirty flag for each character cell that was dirty). Note I did not do the dirty buffer handling inside the ISR either I turned it into an #FF terminated list (well a size 64 array) I think, with a max size of 64 entries, and a flag for "we have more than 64 cells to update, just copy the entire backbuffer" - which was used for first drawing of each level). That turned out to be a pain to implement though and made my actual sprite drawing slower cos I had to update the dirty buffer). I used self modifying code to outside the ISR to signal that we are ready to draw i.e. I replaced the 0 operand in LD A, 0 here:
readytodraw: LD A, 0
OR A
RET Z
by doing
DI
LD (readytodraw+1), 1 ; obvs not really this, I had to LD A, 1 first and LD (readytodraw+1), A
EI
when I was done updating game logic etc. ISR routine would set it back to 0 at the end.
I would recommend preparing as much as possible AFTER drawing sprites for the next frame (e.g. do the shifting for the next frame into per sprite buffers if you have the space for that, you'd need 1 buffer per sprite then though, much more complicated if you have variable width sprites).
Re: Abersoft fig-Forth Recompiled
also, moving the system to $8000, and removing RAM-DISC will leave about 12KB of RAM free for user code. this is quite a lot (the whole system is ~15KB now, or ~18KB with fullscreen editor). so i will prolly ditch RAM-DISC at all, and implement support for TR-DOS and +3DOS instead.
i mean, 'cmon, you cannot do anything serious using tape only! everybody used either some DOS, or microdrives (poor souls!). i never bothered to implement microdrive support in my emulator, and i won't do it in R/W word.
for TR-DOS i will prolly use the whole disk as block storage (maybe with some offset, so you could have TR-DOS directory and some data there), and for +3DOS i can use regular disk files instead (because this is The Real DOS).
i may also separate word headers from compiled code. there is no reason why headers cannot grow from $7FFF and towards $0000. and then you'll be able to create "turnkey" apps on Speccy itself, by saving the compiled code, and omiting all headers. currently, headers size is ~3.5KB, so you'll have 3KB more for your compiled code.
and it will allow to trivially implement word hiding by removing some headers altogether, so you would load your library, and then wipe headers for all internal/support words, leaving only high-level API (this is what i am currently doing in my target compiler, btw).
this way you'll be able to use the system on the real hardware to do some Serious Development. i don't know why, but hey, it's a k00l feature anyway! ;-)
i mean, 'cmon, you cannot do anything serious using tape only! everybody used either some DOS, or microdrives (poor souls!). i never bothered to implement microdrive support in my emulator, and i won't do it in R/W word.
for TR-DOS i will prolly use the whole disk as block storage (maybe with some offset, so you could have TR-DOS directory and some data there), and for +3DOS i can use regular disk files instead (because this is The Real DOS).
i may also separate word headers from compiled code. there is no reason why headers cannot grow from $7FFF and towards $0000. and then you'll be able to create "turnkey" apps on Speccy itself, by saving the compiled code, and omiting all headers. currently, headers size is ~3.5KB, so you'll have 3KB more for your compiled code.
and it will allow to trivially implement word hiding by removing some headers altogether, so you would load your library, and then wipe headers for all internal/support words, leaving only high-level API (this is what i am currently doing in my target compiler, btw).
this way you'll be able to use the system on the real hardware to do some Serious Development. i don't know why, but hey, it's a k00l feature anyway! ;-)
Re: Abersoft fig-Forth Recompiled
@ParadigmShifter, the problem is that i want to make everything easy to use. the idea is that you only call "SPR-UPDATE" word with new sprite position and animation frame, and the system will magically do the rest. i don't want the user to think about interrupts, where to insert HALT, and so on.
as i am doing XOR sprites, the only place where i can draw them without user intervention (and almost without flicker) is interrupt handler.
the idea is to create something like White Lightning (or AGD): simple, easy to use, and fun. and it should be possible to use it on the real hardware (just because i want it that way ;-). let's pretend that it is 1986, and i am releasing a Forth-based game creation/programming system, which will show that it is possible to create real games with such thing. then i will sell it to Ocean to be published under Ocean IQ label. ;-)
as i am doing XOR sprites, the only place where i can draw them without user intervention (and almost without flicker) is interrupt handler.
the idea is to create something like White Lightning (or AGD): simple, easy to use, and fun. and it should be possible to use it on the real hardware (just because i want it that way ;-). let's pretend that it is 1986, and i am releasing a Forth-based game creation/programming system, which will show that it is possible to create real games with such thing. then i will sell it to Ocean to be published under Ocean IQ label. ;-)
-
ParadigmShifter
- Manic Miner
- Posts: 673
- Joined: Sat Sep 09, 2023 4:55 am
Re: Abersoft fig-Forth Recompiled
Fair enough.
I had White Lightning (boxed copy) BITD but I struggled with the Forth since it was so different to what I was doing when I was a teenager (mainly BASIC, tried a bit of ASM but with tapes only, no thanks lol). Then I moved onto The Quill and GAC really. Also I agree that the WL editor sucked balls
I only learnt Z80 after years of writing PS1 games in C since I'd always wished I had been able to do it when I was a teen. Was probably nearly 40 when I started lol
I was too young to work professionally as a games programmer when I was a teen, my Spectrum broke when I was 17 (so went the pub instead from then on lol). It was only after uni/going on an employemt training course to learn C - then the most in demand job skill (and easy because I already knew pascal) I got a job as a PS1 programmer by mistake
Didn't even own a PC until my mid 30s I think! Mathematicians did all their computing on paper back then
EDIT: One thing studying maths does though is it teaches you how to think logically and rigorously. (I also think of loads of mad stuff then realise I was wrong about it and have to edit with corrections lol - but I always try and point out whereabouts my argument falls down - another thing maths teaches you - you will make a ton of mistakes, that's fine, just make sure you correct yourself and don't double down on a mistake - which a lot of people who did CS at uni seem to be bad at...)
I had White Lightning (boxed copy) BITD but I struggled with the Forth since it was so different to what I was doing when I was a teenager (mainly BASIC, tried a bit of ASM but with tapes only, no thanks lol). Then I moved onto The Quill and GAC really. Also I agree that the WL editor sucked balls
I only learnt Z80 after years of writing PS1 games in C since I'd always wished I had been able to do it when I was a teen. Was probably nearly 40 when I started lol
I was too young to work professionally as a games programmer when I was a teen, my Spectrum broke when I was 17 (so went the pub instead from then on lol). It was only after uni/going on an employemt training course to learn C - then the most in demand job skill (and easy because I already knew pascal) I got a job as a PS1 programmer by mistake
Didn't even own a PC until my mid 30s I think! Mathematicians did all their computing on paper back then EDIT: One thing studying maths does though is it teaches you how to think logically and rigorously. (I also think of loads of mad stuff then realise I was wrong about it and have to edit with corrections lol - but I always try and point out whereabouts my argument falls down - another thing maths teaches you - you will make a ton of mistakes, that's fine, just make sure you correct yourself and don't double down on a mistake - which a lot of people who did CS at uni seem to be bad at...)
Re: Abersoft fig-Forth Recompiled
I think Jetpack (and other Ultimate games) erase and draw sprite at the same time, line by line. It sounds like horrible idea but sprites usually move just a little bit so this method basically replaces flickering by possible tearing. Well, you can check how it looks on YT yourself.
Proud owner of Didaktik M
-
ParadigmShifter
- Manic Miner
- Posts: 673
- Joined: Sat Sep 09, 2023 4:55 am
Re: Abersoft fig-Forth Recompiled
Jonathan Cauldwell also mentioned what he does for AGD sprites on the other forum here:
https://worldofspectrum.org/forums/disc ... nt_1013240
^ which is what poster above is going on about, Jonathan borrowed that from Ultimate way of doing it after being informed of it by Joffa
https://worldofspectrum.org/forums/disc ... nt_1013240
^ which is what poster above is going on about, Jonathan borrowed that from Ultimate way of doing it after being informed of it by Joffa
Re: Abersoft fig-Forth Recompiled
by the way, my first contant with Forth was on ZX. i had… yeah, Abersoft Forth, pirated of course, without any documentation. and i had no idea what that "Forth" was. it was on a cassete with other languages (LISP, HiSoft Pascal, etc.), so it was definitely some language, but… what to type there?
and then, by sheer luck, i got Leo Brodie book "Starting Forth". suddenly, i realised what a gem i have in my hands!
i already knew BASIC, Pascal and a little of Z80 asm by that time, so i wasn't scared by stacks and such. Forth was small, Forth was fast (much faster than BASIC!). and i immediately wrote a font editor with it (i was obsessed with font editors at that time, and wrote 3 or 4 in BASIC already ;-).
then i had to abandon Forth for a long time, because nobody even know that such language existed. but i never really forget about it.
now i am using the 3rd incarnation of UrForth (UrForth/Beast: Devastator) to program my x86 PC. and this is prolly the first Forth system i am completely happy with.
by the way, the main reason to develop the original, first UrForth was cross-development for ZX. and now, years later, i am doing exactly this, and with UrForth! ;-)
and then, by sheer luck, i got Leo Brodie book "Starting Forth". suddenly, i realised what a gem i have in my hands!
i already knew BASIC, Pascal and a little of Z80 asm by that time, so i wasn't scared by stacks and such. Forth was small, Forth was fast (much faster than BASIC!). and i immediately wrote a font editor with it (i was obsessed with font editors at that time, and wrote 3 or 4 in BASIC already ;-).
then i had to abandon Forth for a long time, because nobody even know that such language existed. but i never really forget about it.
now i am using the 3rd incarnation of UrForth (UrForth/Beast: Devastator) to program my x86 PC. and this is prolly the first Forth system i am completely happy with.
by the way, the main reason to develop the original, first UrForth was cross-development for ZX. and now, years later, i am doing exactly this, and with UrForth! ;-)
-
ParadigmShifter
- Manic Miner
- Posts: 673
- Joined: Sat Sep 09, 2023 4:55 am
Re: Abersoft fig-Forth Recompiled
I think LISP is probably better as a "programmers" language than Forth (since you can also compile it, but it relies on reference counting or garbage collection as well) of course it's a pain to parse! And the scope of variables is just bonkers innit. (I think Scheme probs sorted that out though?).
Also (singly!) linked lists are pretty crappy especially on 8 bit machines, and terrible these days with caches, you don't want to be following pointers to nearly anywhere, you want to be using contiguous arrays of data.
Crash Bandicoot and Jak and Daxter were written in a variant of LISP (although the person who did most of the coding was one of the world's best Lisp programmers at the time I think). They did it properly though with most speed critical routines having switches for which register to assign to which local variable and such. Also they could recompile parts of the code, squirt it to the PS1/PS2 and the code would then use the new definition immediately WHILE THE GAME WAS STILL RUNNING!!!
When Sony bought Naughty Dog they were like OMG WTF ARE YOU DOING we hoped to be able to share some of your code with our other studios so they made them shift to C++ (which is a horrible horrible language to code in). I'm mainly doing Unity so C# now
EDIT: I have said many times though if I was writing a scripting language for the speccy I would turn it into some kind of forth at the lowest level (I just would write a simple parser on the PC that turns non Forth code into Forth like compiled data for use on the speccy).
Also (singly!) linked lists are pretty crappy especially on 8 bit machines, and terrible these days with caches, you don't want to be following pointers to nearly anywhere, you want to be using contiguous arrays of data.
Crash Bandicoot and Jak and Daxter were written in a variant of LISP (although the person who did most of the coding was one of the world's best Lisp programmers at the time I think). They did it properly though with most speed critical routines having switches for which register to assign to which local variable and such. Also they could recompile parts of the code, squirt it to the PS1/PS2 and the code would then use the new definition immediately WHILE THE GAME WAS STILL RUNNING!!!
When Sony bought Naughty Dog they were like OMG WTF ARE YOU DOING we hoped to be able to share some of your code with our other studios so they made them shift to C++ (which is a horrible horrible language to code in). I'm mainly doing Unity so C# now
EDIT: I have said many times though if I was writing a scripting language for the speccy I would turn it into some kind of forth at the lowest level (I just would write a simple parser on the PC that turns non Forth code into Forth like compiled data for use on the speccy).
Last edited by ParadigmShifter on Wed Apr 03, 2024 12:07 am, edited 2 times in total.
Re: Abersoft fig-Forth Recompiled
with Jetpack they had no luxury to use custom interrupt handler, because of 16KB.catmeows wrote: ↑Tue Apr 02, 2024 11:45 pm I think Jetpack (and other Ultimate games) erase and draw sprite at the same time, line by line. It sounds like horrible idea but sprites usually move just a little bit so this method basically replaces flickering by possible tearing. Well, you can check how it looks on YT yourself.
yet i implemented line-by-line approach, and it mostly worked. i just wasn't happy with it, and wanted something more advanced.
thank you! that's basically what i am planning to do too (including sprite sorting).ParadigmShifter wrote: ↑Tue Apr 02, 2024 11:47 pm Jonathan Cauldwell also mentioned what he does for AGD sprites on the other forum here:
https://worldofspectrum.org/forums/disc ... nt_1013240
my engine actually redraws only the sprite which is moved, so the user can control how much rendering will happen. there is a list of sprites to update in the interrupt handler, and the handler clears the list when it's done. so updater simply prepares the new data structure, and puts it into render list.
i will prolly limit rendering to 5 or 6 sprites per frame, sort that chunk, and blit it.
-
ParadigmShifter
- Manic Miner
- Posts: 673
- Joined: Sat Sep 09, 2023 4:55 am
Re: Abersoft fig-Forth Recompiled
Defo do the sort at the end of the frame though ready for the next frame, don't attempt to sort whilst drawing.ketmar wrote: ↑Wed Apr 03, 2024 12:03 am with Jetpack they had no luxury to use custom interrupt handler, because of 16KB.
yet i implemented line-by-line approach, and it mostly worked. i just wasn't happy with it, and wanted something more advanced.
thank you! that's basically what i am planning to do too (including sprite sorting).
my engine actually redraws only the sprite which is moved, so the user can control how much rendering will happen. there is a list of sprites to update in the interrupt handler, and the handler clears the list when it's done. so updater simply prepares the new data structure, and puts it into render list.
i will prolly limit rendering to 5 or 6 sprites per frame, sort that chunk, and blit it.
Re: Abersoft fig-Forth Recompiled
they aren't that different, actually. both basically provide a "raw" low-level access to some imaginary virtual machine, and you can build your code upon that. Forth is simplier, though, and easier to implement. and faster. ;-)ParadigmShifter wrote: ↑Wed Apr 03, 2024 12:00 am I think LISP is probably better as a "programmers" language than Forth
UrForth (with the help of Succubus) generates direct x86 machine code too. it is only ~2.2 times slower than GCC -O2. actually, it is faster than this, because Forth code is quite different from C, i deliberately tested it on "C-like" code, not on proper Forth programs.ParadigmShifter wrote: ↑Wed Apr 03, 2024 12:00 am Crash Bandicoot and Jak and Daxter were written in a variant of LISP (although the person who did most of the coding was one of the world's best Lisp programmers at the time I think). They did it properly though with most speed critical routines having switches for which register to assign to which local variable and such.
and i am planning to implement even better native compiler for UrForth (Succubus Reincarnated ;-).
yeah, it is quite easy with such languages as LISP or Forth. especially when you have the full control over the compiler (i.e. wrote the compiler yourself).ParadigmShifter wrote: ↑Wed Apr 03, 2024 12:00 am Also they could recompile parts of the code, squirt it to the PS1/PS2 and the code would then use the new definition immediately WHILE THE GAME WAS STILL RUNNING!!!
also, build times! UrForth system (with Succubus) is ~500 KB of source code. i can recompile it in 60 milliseconds (80 with assembler and Uroborus target compiler). yes, MILLIseconds. way faster than some modern software boots from the compiled binary, lol.
-
ParadigmShifter
- Manic Miner
- Posts: 673
- Joined: Sat Sep 09, 2023 4:55 am
Re: Abersoft fig-Forth Recompiled
Yeah they wrote all their compilers and debuggers themselves, in LISP.
Mad lads
They also didn't use any of the Sony provided libraries to save lots of memory.(libraries admittedly pretty crappy at first, on the PS1 at least - PS2 was so hard to program people took weeks to draw a triangle on screen at first I think lol). They reverse engineered the Sony libs and rewrote the bits they needed in LISP (or ASM).
They basically had DLL style loading of code and graphics from the off on PS1 which we didn't really do until the end days of PS1.
EDIT: This is worth watching if you haven't seen it
Mad lads
They also didn't use any of the Sony provided libraries to save lots of memory.(libraries admittedly pretty crappy at first, on the PS1 at least - PS2 was so hard to program people took weeks to draw a triangle on screen at first I think lol). They reverse engineered the Sony libs and rewrote the bits they needed in LISP (or ASM).
They basically had DLL style loading of code and graphics from the off on PS1 which we didn't really do until the end days of PS1.
EDIT: This is worth watching if you haven't seen it
Re: Abersoft fig-Forth Recompiled
sadly, this is something i cannot afford. i don't want the user to call any "LETS-END-THIS-FRAME" routine manually, so i have to sort everything right before i draw it. and "SPR-UPDATE" routine cannot perform sorting too, because the interrupt may be triggered anytime. so the best place to sort everything is right in the interrupt handler.ParadigmShifter wrote: ↑Wed Apr 03, 2024 12:05 am Defo do the sort at the end of the frame though ready for the next frame, don't attempt to sort whilst drawing.
but sorting 6-7 sprites should not be that slow. actually, i don't even have to properly sort them all: what i need is to select 3-4 sprites closest to the top of the screen, and render them first, in any order. by that time the ray will start updating the screen, so i can find and process another batch. i have to write it and check if it will work as i expect it to work, but i think that "rough batching" approach will do the trick.
-
ParadigmShifter
- Manic Miner
- Posts: 673
- Joined: Sat Sep 09, 2023 4:55 am
Re: Abersoft fig-Forth Recompiled
Can't you use a callback function or something for end of game logic/start preparing next frame?ketmar wrote: ↑Wed Apr 03, 2024 12:21 am sadly, this is something i cannot afford. i don't want the user to call any "LETS-END-THIS-FRAME" routine manually, so i have to sort everything right before i draw it. and "SPR-UPDATE" routine cannot perform sorting too, because the interrupt may be triggered anytime. so the best place to sort everything is right in the interrupt handler.
but sorting 6-7 sprites should not be that slow. actually, i don't even have to properly sort them all: what i need is to select 3-4 sprites closest to the top of the screen, and render them first, in any order. by that time the ray will start updating the screen, so i can find and process another batch. i have to write it and check if it will work as i expect it to work, but i think that "rough batching" approach will do the trick.
EDIT: There's never any problem which can't be solved by using an extra level of indirection is what Knuth said I think? Or maybe Djikstra...
Re: Abersoft fig-Forth Recompiled
this will limit the ways to use the system. the idea is that you can move the sprites anywhere in your code, when you want it, not when the system wants you to do it. you command — the system obeys, not vice versa. ;-)ParadigmShifter wrote: ↑Wed Apr 03, 2024 12:23 am Can't you use a callback function or something for end of game logic/start preparing next frame?
i want to let the user to split the game logic code as they want to, and to interactively debug any part of it. call "MOVE-NASTY" word from the interpreter prompt, and see the nasty made one step, for example. and so on.
just don't forget that we have a language that is both compiled and interpreted. interactive debugging is the important part of Forth programming, i don't want to throw it away.