Denial

AndyH wrote: ↑Sat Mar 04, 2023 6:07 am BTW, has anyone got the DSK / PRG for the Sprite-Imation ... be interested to have a look at it (the links in this thread are no longer working).

I haven’t dropped in here for quite a while, so I didn’t notice the activity in this thread again. I can probably dig up the original article and code for the Sprite-Imation. I’m a bit of a magpie when it comes to code.

I never progressed any further with the commenting of the disassembly code.

As mentioned above, there are some very good other software sprite options available now. My only regret is that I never sat down at the one project long enough to learn how to use them adequately.

Hawk

It would be interesting to see if you find them.

Btw, I made a other enhancement which I don't think I mentioned that might be of interest to others writing sprite routines. Possibly a retread of what others have done before me, I don't know...


In trse there is a character map editor where you can design your characters and sprites, and a bunch of export commands to extract a binary of the character data when you build your project. I extended these exporters.

I added a command that exports the sprite data as code instead of raw binary data. The code just draws the preshifted sprite with a series of lda/sta's.

The exporter also ignores zero data (so no code is generated) and also groups the same data values together. Both of these save lots of bytes and processor cycles to draw them. The speed boost is good, not sensational but you might get to draw an extra sprite with the savings, and the total size is often on-par, sometimes better than a raw binary data export.

AndyH wrote: ↑Mon Jul 31, 2023 3:31 pmI added a command that exports the sprite data as code instead of raw binary data. The code just draws the preshifted sprite with a series of lda/sta's.

Neat! So each frame of animation would have its own set of dedicated render code?

Here's a copy of Sprite-Imation. This package includes a copy of the original article, the programs and demos, as well as my disassembly, as far as I got.

Hello,

I've always been interested in sprites. I only got to know the Sprite Imation program from Compute last year. If I had known about it in 1985 it would have been great. Unfortunately, I didn't have access to Compute's great books at the time!

That's why I was keen to complete the program that Hawk brought in. Unfortunately it doesn't work 100% yet. There is a problem with the graphics addresses. Somehow I don't get the change between Poke 36869,240 and Poke36869,254 displayed correctly. Can someone here perhaps provide support? If the program is in memory, the correct start screen is displayed, but the sprite is not.

The program and the source codes are included. The Sprite-Earth-Demo can be drag and dropped into the VICE emulator.

PS: Of course I know Rober Hurst's VIC Sprite Stack, which is far better.

Hello,

Is there anyone out there who can help me with my question? I can't find the error in the program or in my thought process.

Thank you

MrSterlingBS wrote:I don't get the change between Poke 36869,240 and Poke36869,254 displayed correctly. Can someone here perhaps provide support?

Judging by the disassembly, all the code ever does is writing $F0 to VIC register $900F, during init.

If $900F was supposed to be changed to another value than $F0, the corresponding code is notably absent.

The version of Sprite-imation uploaded by hawk uses a user-defined character set (embedded in the program) at $1800. When the program is installed it enables the character set by setting $9005 to the value $fe. Your program seems to want to use the default ROM characters by setting $9005 to $f0. You need to make sure you include a character definition data set at $1800 and activate it by setting $9005 to $fe.

I have attached a disk image which includes the original SPTIM PRG, the SPTDMO1 PRG and a copy of your BASIC Sprite-earth-demo as EARTH PRG.

Using VICE xvic, configure the model as either unexpanded or +3K.
Attach the disk image.
Load the sptim program using LOAD "SPTIM",8,1
SYS6000 to run the sprite extension.
Load the Sprite-Earth program from the disk image using LOAD "EARTH",8
Run the BASIC program
.

Good morning,

thanks a lot for your help.

Bur, it wont run. If i run the program from my assembler compiler the same failure occurs.
The data of the sprite is not correct.
If i change the register $9005 from $F0 (240) to $FE (254) the start text cannot be seen.
And vice versa I see the text but the sprite does not contain the correct data.

I do not know why?

My Assembler load the program with Load"Demo",8 ant not with ,8,1.
Could that be the error?
And how do I change my basic stub to load the program with .8.1?

MrSterlingBS wrote:The data of the sprite is not correct.

With VIC register $9005 set to 240, the only thing the VIC-I chip does is - displaying the ROM character set.

If i change the register $9005 from $F0 (240) to $FE (254) the start text cannot be seen.

As @thegg already wrote, you need to supply a copy of the ROM character set in RAM, at $1800. Part of that RAM based character set is then used/overwritten to contain the Earth 'sprite'.

I do not know why?

We are really talking about basics here. You cannot expect VIC-I be able to display those 'sprites' with the ROM character set being active. $9005 needs to be pointed to (the internal) RAM, so some of the user defined characters placed there can be repurposed to display the 'sprite'. If you still want to display the other stuff as background graphics, you need to make a copy of the ROM character set into the user defined character set beforehand.

As I already wrote, the 'sprite' display then repurposes some of the characters in the character set RAM copy for the 'sprite' display. It follows those character codes used for the 'sprite' (here, Shift-L up to Shift-W) are not anymore available for other background graphics (they will just show parts of the 'sprite' at other places on screen which you likely do not want). This is no fault peculiar to Sprit-Imation: the display of 'sprite' graphics with VIC-I will always use (part of) a user defined character set, and exactly those chars are then committed to that use and are not available for other things.

...

That being said, what I wrote in my posting from Feb 28, 2023, still applies:

Sprite-Imation, as interesting as it seemed at the time the thread here was conceived, ultimately suffered the fate of a binary executable with no further documentation than what was given with the magazine article, having mostly only one example/demonstration program, without source, no easy way to adapt it for bigger RAM setups and also being too ambitious in its ideas: unlike the sprites on the C64 which have their own colours and are definitely independent off their background, this simply cannot be achieved with the VIC-I video chip. The simple act of scrolling the screen destroys any illusion it could be done that easily on the VIC-20.