Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Fourspriter: Alternate Version
#31
I want to apologize for the tone of the above message. I think it was a bit uncalled for, I'm having a hard day and this has affected me way too much. It was just a misunderstanding and I deeply apologize for my behaviour.

I'm very fond of the enhacements you have done to the library.

For the record, one of the reasons I changed the data format is that this library was originally developed to be used from Sinclair BASIC using plain addresses, and calculating the addresses is easier when the data block takes 50 bytes instead of 48. Using it from ZX Basic, embedded in SUBs and FUNCTIONs change this scenario, so if you prefer taking the v1 as a base and enhacing it to be included in the compiler as a library, I'm fine and encourage you to do so.
Reply
#32
Woah!

Na_th_an, at the time I was a little nonplussed, partly because I'd just spent ages working on the code to improve it, and version 2 came out more or less....right then. And, yes, there were similarities. I did suspect that ideas had been lifted, but my friend, it was totally not worth pursuing to me. I never assume malice where an error could have occurred anyway - that is, even if you HAD and forgot to mention me, I was glad that the code was out there for people to use.

First up, even though you retracted your statement, I unreservedly apologize for anything I said upsetting you. That's absolutely not why I am here. I am VERY sorry.


How about this for making peace - I have a newer version, part written. I built it from scratch, but using the principles of fourspriter (four sprites, for example, but no longer based on UDG) Actually, the machine code part works. It's lightning fast. I just haven't had time to finally make it work without problems. Would you like it?

I got to the point of wanting it to check for collisions, and not print both sprites that overlap in case of a collision (because buffer and redraw occur together, and if both sprites overlap, it buffers the other sprite instead of the background). So what isn't quite working are the other functions that go around it. I can get it to put at least three of the four sprites against the top of the screen, and the fourth might have to live with being one line lower. I'm using PUSH and POP to draw them instead of LDI. The version listed here is only flicker free because of a long wait loop to wait for the TV scan line to pass. The new version puts the sprites up BEFORE the scan line even gets to the screen. I've fought for every instruction to make it speed-speed-speed after the HALT starts the redraw cycle.

Unfortunately, right now, I'm tied up with other things. But I'm perfectly willing to hand over what I have, if you or anyone else wants to make it into a standalone piece of code or a library for Boriel's ZX Basic.
Reply
#33
It sounds incredibly good. I'd like to take a peek to learn how to use PUSH/POP for such endeavours, but, just like you, I'm completely busy right now and wouldn't be able to give it the attention it deserves.

The fastest version should be included in the compiler as a library Smile
Reply
#34
britlion Wrote:[...]The version listed here is only flicker free because of a long wait loop to wait for the TV scan line to pass. The new version puts the sprites up BEFORE the scan line even gets to the screen. I've fought for every instruction to make it speed-speed-speed after the HALT starts the redraw cycle.

Unfortunately, right now, I'm tied up with other things. But I'm perfectly willing to hand over what I have, if you or anyone else wants to make it into a standalone piece of code or a library for Boriel's ZX Basic.
Well, I would like to explain how to embed it into a SUB PutSprite() ... END SUB block, but you already know that. :wink:
Reply
#35
Sent by email!
Reply
#36
britlion Wrote:Sent by email!

Great !

I'll be checking it as soon as Boriel puts it in the library Smile
Reply
#37
boriel Wrote:Well, I would like to explain how to embed it into a SUB PutSprite() ... END SUB block, but you already know that. :wink:

Just one SUB block? It sorta needs more now, unless you want subsub blocks! :-)

There's a few functions that run it, such as initialize, recolour, and so on. Might be nice to have one that changes the graphic for animated sprites. It's all fairly manual - but that does make it under programmer control. Right now the only limitation would be four sprites at once, and sized at 16X16 pixels. It can use graphics and colour data from anywhere.

But the whole sprite code is embedded in SUBs, yes.
Reply
#38
My first post in Zxb Boriel forum. Hi to all, sorry by my bad english. I´m reading the nathan manual of four spriter for the Bytemaniacos contest, and I think I make my subs or maybe functions to control the "thing".
I think this manual make me an idea of the potential of animate sprites and make loops for the sprites and also. I smiled when I readed "llenar la pantalla de mierda de colorines"="full the screen with colours shit". Big Grin
Reply
#39
Welcome, compiuter. :!:
At the moment I'm rather busy. Britlion has sent me and updated version of FourSpriter. I will try to package it this weekend.
I have also some proposals to port or create a generic sprite library (like splib). But this would be in the long term.
Reply
#40
Hi boriel!
the idea to include generic Sprite library a la Splib 1 sounds excellent, even if a long-term project. I hope you will add the functions and improve and add further functions with new releases. I want then to add a Sprite/Map editor in my BorIDE too, to support this.
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
Reply
#41
Hi Compiuter! Welcome!

For the record, note that Fourspriter version 1 is already available for the compiler. It's up and it works - at this point, version three is about speed improvements, since the original is a little inefficient in the way it works. I worked out that with speed improvements, there could be a real frame rate improvement.

Boriel - I absolutely support a generic sprite library system. That would be beyond awesome. I was looking at the Sprite Library for C, and it's very embedded stuff, that; requiring IM mode 2 and quite a lot of memory in full use. However, it's possible to cut down the amount of memory used for buffers and back-screens by reducing effective screen area. I'm not quite sure how all that could work in ZX BASIC as it stands, which doesn't really have the interface at the moment.
Reply
#42
britlion Wrote:However, it's possible to cut down the amount of memory used for buffers and back-screens by reducing effective screen area. I'm not quite sure how all that could work in ZX BASIC as it stands, which doesn't really have the interface at the moment.
Interface is not the question. If you tell the compiler to use a screen area using command line,you won't be able to draw anything outside, not even the score an a panel. I think about defining Backbuffer area with a own BASIC Command: BACKBUFFERr xpos, ypos, width, height [,adress]
A variable adress of screen for all drawing routines (PLOT, PRINT, etc.) would allow to use a own screen buffer or second screen on Spectrum 128:
DRAW AT 49152; x, y (AT as optional modifier to define adress of screen)
:wink:
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
Reply
#43
LCD Wrote:
britlion Wrote:Interface is not the question. If you tell the compiler to use a screen area using command line,you won't be able to draw anything outside, not even the score an a panel. I think about defining Backbuffer area with a own BASIC Command: BACKBUFFERr xpos, ypos, width, height [,adress]
A variable adress of screen for all drawing routines (PLOT, PRINT, etc.) would allow to use a own screen buffer or second screen on Spectrum 128:
DRAW AT 49152; x, y (AT as optional modifier to define adress of screen)
:wink:
I designed ZX BASIC with that in mind from the beginning. There's a "ZX SYSTEM VARIABLE" used for Screen Address. But only PRINT and CLS make use of it at the moment: Drawing primitives relay in ROM PLOT routine which is fixed to 16384. Solution: The user might specify a "Adressable PLOT" flag, so the compiler also include a PLOT variant which also uses this variable.
Reply
#44
in the demo, why is there a bunch of black dots in the background,
and how do they not get overdrawn by the sprites?
like how do they not get wiped off the screen

also
did this ever get added as an official library? its seems very good
Reply
#45
slenkar Wrote:in the demo, why is there a bunch of black dots in the background,
and how do they not get overdrawn by the sprites?
like how do they not get wiped off the screen

also
did this ever get added as an official library? its seems very good


Fourspriter saves the background before it draws a sprite on it, and then replaces this background to erase the sprite. This means you can use it with a background without worrying about the background being destroyed.

Like this: <!-- m --><a class="postlink" href="http://britlion.googlepages.com/Sprity.z80">http://britlion.googlepages.com/Sprity.z80</a><!-- m -->
(break in to the basic, if you dare! [The standard routines here aren't interrupt driven])

Yes, this is in the library just #include <fourspriter.bas> to get it - but the functions have been renamed and redescribed when Boriel did some rewrites in it. You should have a look at fourspriter.bas in the library directory where you installed zxb to get the usage; it's not well documented, and I think it's based on the oldest version of fourspriter.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)