I don't know how to call this, but heretic might be close. Let me explain what happens:

I'm making my crap game and I'm following strictly the programmers manual of good practics, you know, first I do the loading screen, then I do some graphics, sprite first and then the backgrounds and at last I try to do some code to move the whole thing with QAOPM (it could be I'm reading the manual upside down, yes).

Now I'm at the stage where I have the sprites done and I'm making the rooms' background. At this stage I just draw it all on the screen and when I'm happy with an item I add a ' before the line to make it a coment and move on to the next item. When I have everything, I will sort it all out.

Well, I had the first room layout. I did a carpet to decorate it. It was ok so I greyed it out (with the ' ) and started to desing a "David Star". When I print it, the first two graphics of the sprite data (which happen to be the mask for the sprite looking down) are corrupted. Somehow it seems that the background data (made with plots and draws) is overwritting the beginning of the sprite data. The strange thing is that if I print the carpet first and over it I print the star, nothing happens. And if I print the star making it double lined, everything is OK too.

So I'll send you a package with the code and attachements so you can check it if you want. No need to hurry up, I can workaround it and go on with the game.

Apenao

Attached Files

  gentle.zip (Size: 7.72 KB / Downloads: 1167)

It would be nice to be able to map the program produced in memory, work out where it is - and optionally, where gaps are (very useful for IM2 stuff) so that the gaps could be used. Even if only as buffer memory for other functions.

SUB <name> as interrupt
stuff
end sub

would be pretty awesome.

A clever compiler could follow this as a code entry point separate from the main thread and assume any variables or functions called would actually be used.

A really clever compiler would explain that PAUSE was a bad idea. As is HALT in any ASM chained - because it would have disabled interrupts and re-enabled them at the end.

Hi,

I've been working very hard in fixing almost 10 obscure bugs in the -O2 and -O3 options. And they finally seems to be fixed. Apenao's game compiles with -O3 flawlessly and plays well (obviously, -O3 includes -O2 optimizations); but I need more testing. So anyone who has programs to test both -O2 and -O3, and check if it compiles and behaves as it does with no optimization at all.

If everything works ok, I expect the compiler will behave more intelligently than ever before. It's been ultra-hard hock: :roll: but I hope it's worth the hassle.
You can download .zip or .tag.gz 1.2.5 files, or the MSI windows install: <!-- m --><a class="postlink" href="http://www.boriel.com/files/zxb/zxbasic-1.2.5r1513.msi">http://www.boriel.com/files/zxb/zxbasic-1.2.5r1513.msi</a><!-- m -->

This is the final version, unless I /really/ have to mess with it more.

MK III might be better for people that want more time between sprite updates to do things - but they might get flickery sprites. This version is quite a bit slower, because after a halt to sync to the screen it waits for the screen to be drawn, and then plays with the sprites. This is a hold of about 1.5 frames per update doing nothing at all.

A clever programmer could probably steal some of the "wait for the screen to draw" time for their own purposes, if they had code that ran in fixed time.

On the plus side, this version is rock solid flicker free. Which was the point of the exercise, after all.

NOTE: There's an addition to the original useage. It has testing code built into the functions so you shouldn't be able to break them. When you are happy that the program runs fine, put #DEFINE FINAL_CODE into the program early on, and it will remove the boundary checking code. (and thus be a little bit smaller).

So... if I was crazy and wanted to implement an IM2 routine.... how do you think I should do it?

Most of my attempts to put the 257 byte data block in memory have failed spectacularly. I think using ORG in an asm statement tends to upset the compiler; but the thing about setting up interrupts is we NEED to put a 257 byte vector table into a very very specific location in memory, and then need to ALSO have the actual interrupt service routine in the specific place that the vector table points to.

*ponder*

I suppose we could use DIM variable @address to force the issue with an array?

On the whole though, this fixed location code isn't really supported by the compiler at this time. How could we work around it?

Okay, reduced the flicker quite a bit more.

Sadly, because it's erase all four sprites and then redraws all sprites, different sprites start to flicker at different points.

If using 4 sprites:
Sprite 0 starts to flicker at above (pixel) line 10
And every other sprite at about 8 lines further down, per sprite.

If using 3 sprites
Sprites 0 is stable
Sprite 1 flickers above row 6
Sprite 3 starts to flicker at above line 16.

If using 2 sprites
Everything is stable.

I assume this is why the mojon's demonstrations only use 2 sprites...

I can't see any more speed optimizations (and right now it probably completes a redraw cycle in less than half the time of the original). There are probably some left, and no doubt Boriel will spot them immediately because he's a genius. However, right now I'm looking at changing /how/ it works. Things like not redrawing a sprite if it hasn't moved, and rather than erase all sprites and then draw all sprites, perhaps go for an erase-buffer-draw routine that does it on a per-sprite basis; limiting the time in which flicker can hit to areas of the screen.

The only alternative to that is to use a back-buffer screen; and that's a LOT of memory.

So right now, it's perfectly useable, if you think about where your sprites are going to go on the screen. The more sprites you have, the more careful you have to be - and keep the later numbered sprites away from the top of the screen!

So, here's how it stands right now (with a tweaked version of Apenao's demo program):

I'm getting an error in the code "illegal character _ at line xxx"

And there isn't one in line xxx.

I suspect that this line number comes from the assembler, and it's a line number based on the code stripped of comments and white space perhaps?

I've noticed that it's sometimes hard to pin down the correct line number for errors before.

I've never used it at all; but I hear that it's a nice code control system.

How does one get going then?

Do you use windows, or linux?

I've made quite a few changes to the actual FourSpriter code. I have made it significantly shorter, and not a small amount faster in execution, using tricks like LDI to copy directly from (HL) to (DE) as opposed to copying into and out of the A register. I removed at least one redundant section of code that was identical with another one - redirecting calls took care of that. There are also places that use bafflingly long code to do something simple. For example: