Clipping the sprite at the edge of the screen.
ZXNet echo conference «code.zx»
Hello, moroz1999
What are the sprite sizes? Are all the sprites different sizes or the same?
if they are not very large and identical, then you can (you need to read) decrement them
shifting along X and creating several output procedures (by the way, outputting with a “snake” especially
you won't speed it up).
Let's say there is a max size in X in the familiar places will be 4, then you create the following
procedures for withdrawal
X <= (-4*8) : fuck it
X > (-4*8) && X < (-3*8) : proc_m1
X>=0 && X<255 : proc_normal
X>255 && X<(255+8) : proc_p1
here.
very good quickly ;)
but not optimal for memory.
-+----
or like this: there are 3 procedures, the sprites are messed up
1) the sprite climbs to the left
2) the sprite is completely on the screen
3) the sprite climbs to the right
If the sprite is on the screen, then everything is obvious.
Let's say the sprite climbs to the right.
if the output of 2 lines is like this:
┌─- code ───
line_1:
ld a,(bc)
inc with
ld d,a
dup max_width-1
ld a,(de)
and (hl)
inc hl
or(hl)
inc hl
ld(de),a
inc e
edup
ld a,(de)
and (hl)
inc hl
or(hl)
inc hl
ld(de),a
ret
line_2:
ld a,(bc)
inc with
ld d,a
ld a,
add a,l
ld l,a
dup max_width-1
ld a,(de)
and (hl)
inc hl
or(hl)
inc hl
ld(de),a
dec e
edup
ld a,(de)
and (hl)
inc hl
or(hl)
inc hl
ld(de),a
ret
└── code ───
then you can calculate where to put the required ret (so as not to display too much),modify line_1 and line_2 for these purposes, we will also write
cut along Y and further
┌─- code ───
; b - number of 2x lines for output
; hl' - points to the desired location of the sprite
; e' - column in the screen
; c' - line number on screen
; b' - address of the address plate
ld hl,retaddr
push hl
ld hl,line_2
ld de,line_1
lp0:
push hl
push de
djnz lp0
ret
retaddr:
....
└── code ───
! the code will not work!
there is a problem with what is displayed as a “snake” - then it won’t work out so easily
get addresses from the sign.
better without a snake. and from the sign you need to get not only the senior part of the address
(in this case D) but also the minor one (E) and add an offset to it
In general, I think the idea is clear.
Hello, moroz1999
The sprite is stored correctly (mask - spr.)
but the fact that you can’t grunt is bad...
why is there a 8 keel on the sign?
┌─- code ───
RRtab:
DB %00000000,%00000000 ; %00000000
DB %00000000,%10000000 ; %00000001
DB %00000001,%00000000 ; %00000010
.... 256 times
└── code ───
it turns out to be about 4 kilos.
By the way, you can optimize the sprite output if the offset == 0, but I think there’s no point
does not have.
Is that how you deduce the “snake”?
┌─- code ───
.... output 1 line ....
CALL DOWN_DE
.... output 2 lines ....
CALL DOWN_DE
└── code ───
if yes, then replace DOWN_DE with a selection from the table, but then the snake will be difficult
it will be ;)
Hello, All
I know quite a bit of theory on this issue, maybe someone can tell me
some tricky solutions to the following question:
There is a procedure for displaying sprites on the screen with the following parameters:
output coordinates - pixel-by-pixel,
The X-dimensions of a sprite are multiples of 8 pixels, Y-dimensions are multiples of 2 pixels.
The output to the screen is the so-called. “snake”, i.e. odd numbers are displayed from left to right,
even for speed from right to left.
The output is sent directly to the video memory area.
question: how, in theory, is it easier/faster/smarter/more optimal to trim a sprite,
extending beyond the edge of the screen?
Hello Sinus
thanks for the info.
I'm sorry, my mistake - I didn't post all the requirements.
so, the size of the sprite is very arbitrary, I was already thinking about writing
Each size has its own conclusion, but there are so many different ones.
I can’t unpack the sprites - there are a lot of them. to find an acceptable
speed, a kilobyte by 8 table is used, containing all offset options
bytes
sprites are stored like this:
mask byte, sprite byte, mask byte, sprite byte..., naturally for a snake.
By the way, in a pinch, it’s easy to give up the snake.
Hello Sinus
and more. You won’t be able to do anything with your frame requirements.
so there’s no need to worry too much about speed and winning every beat
sense.
It’s better to fix everything under a timer, so that everything becomes cool with the turbo, but doesn’t fly away.
and without a turbo it will slow down, but without slowing down the gameplay....
(or are you not making a game?)
Hello, Wlodek
Wlodek: if the sprite climbs vertically, then you can stuff it into ROM;)
what if horizontally?
or do you suggest getting every byte from the tablet? this is slow.
Hello Sinus
The general idea is this: use a table (or two tables :) to display the sprite.
) video memory addresses and provide several bytes or words in each of them
dummy addresses outside the screen, depending on the maximum size
sprite. Back in 1989, I successfully used this in “Adventure in the Subway” :) .
Hello Sinus
Horizontally, you can imagine that the screen is not 32, but 33,
34, etc. familiarity (depending on the actual maximum size
sprite). Vertically - it’s true, as many “extra” lines as there are “extra”
links from address tables. I say, it’s really simple and elementary. Procedure
sprite output doesn't even think about the fact that it's actually a series
pixel elements are not displayed on the screen, but, for example, in the ROM address area.
No "if" jumps, no branches. I say I used it and
happy ;) . And the table of addresses in memory - well, today the minimum is 128K! And I'm in
In 1989, I crammed everything into 48K without any problems ;) . Total 41K, with all tables,
sprite images, graphics and, of course, program code. Everything is much better now
more comfortable ;) .
Hello, Wlodek
Horizontally, you can imagine that the screen is not 32, but 33,
34, etc. dating places
This is understandable, as they say, this is not the first time I’ve been married.
I like to quote myself in such cases:
> or do you suggest getting every byte from the plate? this is slow.
>
i.e. For each byte output you take the address from the tablet.
and I say that it is BRAKEY! ;)
Hello axor
axo> You can make the screen not full width, but put attributes around the edges
axo> (the width of this strip depends on the max width of the sprite), which
axo> matches ink and paper.
axo>
axo> That is. we print as usual, and the user sees that the sprite is gone
axo> right/left. Well, we need to work out going beyond the actual screen size
axo> as necessary.
Yes, this was done in some demos and toys.
but IMHO not the best solution.
especially since it is not always applicable - for example, if the game is not in full screen, but in
"frame". you can’t really arrange the attributes there
Hello, Wlodek
You can make the screen not full width, but put attributes around the edges (width
this strip depends on the max width of the sprite), which have the same ink and paper.
Those. We print as usual, and the user sees that the sprite has moved to the right/left.
Well, going beyond the actual screen size will have to be worked out as best you can.
Hello Sinus
double mask. those. to the mask that the sprite itself has, add another mask.
If the sprite is 2 or 3 bytes wide, this mask can be used before outputting the sprite
load it into the registers with a prime, and keep it there for a little speedup.
If you don’t like the slowdown, do 2 options for the withdrawal procedure, option with
an additional mask only works for sprites that have “traveled” beyond the edge.
Is the idea clear?
Hello Sinus
Sin> yes, this was done in some demos and toys.
Sin> but IMHO not the best solution.
Sin> especially since it is not always applicable - for example, if the game is not in full
Sin> screen, but in a “frame”. You can’t really arrange the attributes there
But at least the easiest way :)
Hello, acidrain
acidrain Well, firstly, it wasn’t me who proposed such a solution (by the way, it’s possible not in ROM,
and to any free space in RAM), and secondly, if there is a page of RAM, then you need
Some bit in some port prohibits writing there.
;) or do a disconnect ;)
Hello axor
Fixed width sprite? If so, then you can write a set of subprocedures like:
;if it fits entirely
put_all:
dup N
ldi
edup
inc d
dec e
dup N
ldd
edup
inc d,e
ret
;if K does not fit the familiar place on the right
put_noK:
dup N-K
ldi
edup
inc d
dec e
dup K+K
inc hl
edup
dup N-K
ldd
edup
inc d,e
dup K+K
inc hl
edup
ret
Naturally optimize address correction in HL
the output will be to call the desired procedure.
plus cutting off invisible sprites. In total we have 1 full withdrawal procedure, N
procedures for output beyond the right edge and N procedures for output beyond the left edge.
PS: the code can be remade as a mask
Hello Sinus
Sin> yes, this was done in some demos and toys.
Sin> but IMHO not the best solution.
Sin> especially since it is not always applicable - for example, if the game is not in full
Sin> screen, but in a “frame”. You can’t really arrange the attributes there
The solution is excellent, I’m keeping it in my head as an option at the moment. don't care until
frames, the main thing is gameplay :)
Hello Sinus
Sin> then you can stuff it into ROM
What if there is an atm and a page of RAM instead of a special ROM and you screw up the axis? %)
Hello, moroz1999
so this... it seems like your sprites are big???
or mekie?
if they are small, then it is better to write procedures for all occasions.
and if they are large, then what fields will need to be black (read INK=PAPER)
leave???
Hello Sinus
Damn, I really slow down after work :o
Hello, Soplik
1) braking
2) it’s easier to crop a sprite than to figure out where the screen is damaged
3) slow ;)
Hello, moroz1999
And if you throw it without any checks, and the damaged screen quickly gets clogged
background?
Hello, Soplik
Sop> And if you throw it without any checks, and the screen is damaged quickly, quickly
Sop> score in the background?
A situation may arise that, in addition to the background, there will be a sprite on the other side.
Hello Sinus
I already understand.
Is it necessary to display all sprites pixel by pixel?
Hello, Vladimir Kladov
Vladimir Kladov: a very good solution, but unfortunately it won’t achieve frameability.
although I (when I was testing my mule) looked at a couple of old toys (Hydson Hawk
the same) - not much of a frame, but no less playable
Hello Sinus
well, I don’t focus on framing, IMHO, it’s impossible to write more or less
a sophisticated arcade game that fits into a frame.
Hello, moroz1999
There is another solution: build the entire frame in a buffer with a sequential
organizing the lines, and at the same time making the lines wider, adding on both edges
the required number of bytes (the size of the maximum sprite minus 1). When transferring
trim. Works even when the entire width of the playing field is used
and when there are frames and not only frames ink=paper. And it’s very good when the game
the field is narrower (and for example on the right there is something else like the command menu in a laser squadron).