VileR wrote on 2023-04-15, 09:58:
Nice! Can confirm, all is well on the 5160 now. I played through a few puzzles in succession, had my progress saved and everyt […]
4xtx wrote on 2023-04-15, 01:34:
I don't know if this solves all of the problem but I haven't seen it crash since I made the change.
Nice! Can confirm, all is well on the 5160 now. I played through a few puzzles in succession, had my progress saved and everything, so I think it's safe to say that there are no other issues.
4xtx wrote on 2023-04-14, 23:22:
What's curious to me is: why the lack of FPU on my 8086 luggable and 8088 desktop does not cause this problem.
Yeah, I can't tell what that's all about either. If there's an elusive bug somewhere in the QuickBasic library, there may be unintended consequences due to some external factor - say something BIOS-related, or the contents of uninitialized RAM.
Anyway, congrats on nailing that one down. If you intend to develop this game further, I hope you could give some thought towards speed optimizations. On a 4.77-MHz 8088, it appears that two areas in particular could benefit: graphics-related routines, and the loading of the puzzle sets from the main menu.
I'll wager that space requirements could also be brought way down if you took all those small files and clumped them together into a single one, which could be compressed. The only hurdle is with the background images, since lots of unordered dithering usually means poor compression ratios.
Thanks for replying back, and thank you for your help. I'm pleased that bugs done with! 😀
I'll add a third - the word list generation in xyPE - it is glacial on an XT.
With xyWords I did put a setting in to remove "fancy colors" and I find this speeds up the text-related routines and will limit post-processing in general.
There's two styles of text, one being a manipulated print command based on the screen 1 text mode and one (the smaller) are actually individual sprites that get post-processed. If you turn fancy colors off it will make the UI a bit snappier.
The redrawing of images, bit more tricky - I am just using BLOAD which is a raw binary load of the image into the video memory.
I can keep a few BLOAD contents in RAM but I started to run out of room very quickly given I am targeting 384KB (with a stretch of 320KB).
The puzzle loading (in collection mode) is slow as it needs to generate some statistics and there are a few disk reads.
This one definately could use a re-think as my original concept to display them has turned out very different to reality!
With regards to developing further - I am half and half to be honest.
This was a fun project, but it took up a lot of time and I have a gigantic backlog of hardware and software projects on the go for my main hobby.
I think I'd rather get the code to a state where I'm comfortable with releasing it as open source. Not that there is a gigantic QB community out there thesedays, but there might be some lurkers 😀
I made a detailed user manual explaining many of the games concepts, file formats, methods, etc.. so I reckon there's a good base to start from.