Line

Page 6/10
1 | 2 | 3 | 4 | 5 | | 7 | 8 | 9 | 10

By PingPong

Prophet (2821)

PingPong's picture

12-08-2012, 21:27

hit9918 wrote:

What was the problem again with the failed STOP command?
Like, when restarting, it starts in the next scanline? I forgot.

Yes, it was a similar problem, it starts on the same scanline, but from x=0 (assuming X> 0 when stopped)

hit9918 wrote:

Can one maybe switch it to point search mode?
Maybe it will finish that one without popping over to next scanline.
Then again start with the desired copy command.
Just random brainstorming.

Sorry. i cannot understand. can you explain a bit more what are you thinking?

By hit9918

Prophet (2551)

hit9918's picture

13-08-2012, 20:23

I got another test idea:
is set-adjust able to stretch the display in the middle of a scanline?
If yes, if a scanline can be broken to pieces, then the model "delay all display at start of the scanline" was wrong.
Instead, it is some more functional (typical for hardware) way that in every cycle calculates "the X for display is the beams X getting added the adjust value".

And this would mean the DMA slots get moved immedeately when writing adjust register.
In the "delay counter" model, the slots would move after next horizontal blank.

Another test idea:
Is always the whole tail of a blit wrecked, or maybe after some lines things are ok again?
If always the whole tail is wrecked, this speaks for the "sync on command start" theory.

But, I don't see these things as top priority in game dev. For MSX2 scroll, the blitter copy is sync to vblank, so just manualy split the blits same size as the screensplit. For software sprites, you can in software just repeat the whole recent blit.

And for the scroll blits to work nice, top priority for emu is to get the blitter speed right, even when not simulating all vram slot detail.

By hit9918

Prophet (2551)

hit9918's picture

13-08-2012, 22:01

This somehow got me into an idea for a MSX2 engine.

Using screen 7. Because of the screen 8 sprite color problem, screen 7 is the top game mode.
screen 7 scroll 1 pixel per frame like screen 8.
I hope emu is right and set adjust still works in same range as screen 5, else speed problem.

Then, in about 150 rasterlines dump MSX2 sprites, all color AND pattern Big smile

So you could add vertical roll, and the sprite dump can flee from the rolling screen 7.

This means you get:

diagonal scroll in the extra hires screen 7 that the sega mega drive forum does envy.
and have sega master sprites with 64k sprite pattern! why, because all sprite vram gets dumped.
after the dump, got 100% cpu of a C64 left Big smile do not complain Tongue

The sprite engine can be used independantly of the screen 7 idea.
The sprite list is pointerarray pointing to a struct like this:

Y X 16bit_P 16bit_C

16bit pattern pointer, 16bit color pointer. whoops.

example pattern dump:

pop hl ;next from sprite list
inc hl ;skip Y
ind hl ;skip X
ld e,(hl) ;P lo
inc hl
ld d,(hl) ;P hi
ex de,hl
32 times outi
dec a ;sprite count
jp nz, the loop

SAT dump:

pop hl ;next from sprite list
outi ;Y
outi ;X
out 98 ;dummy color. in blank area should not be too fast for VDP.
out (c),a ;8 bit pattern pointer. do ld a,0 before the loop.
add 4 ;just increment pattern pointer. because pattern dump goes linear with sprite list just like SAT.
dec e ;sprite count
jp nz, the loop

for reverse flicker with POP instruction,
need to maintain a reverse version of the sprite pointerarray.
If you don't want that, do the copy codes MSX1 ringbuffer style.

The games will typically look like this:
Masses of sprite pattern. A tendency of shameless animation as the coder does flip patterns at zero speed penalty.
Masses of sprites without "MSX2 typical" flicker.
Because e.g. Undeadline does flicker caused by doing strange multiple SAT caused by wrestling the colorbyte quirk, not by 9th sprite.
You code less but get more performance!

p.s.
one could give up the ability of single linecolor sprites and then get more easy two-sprite colorsprites.
The two-sprite colorsprite then is like one rock solid sprite from programmers point of view.

Changes:
In pattern and color dump, just double the amount of outi. Two hardware sprites filled per one sprite list entry.

Then this SAT dump:

pop hl ;next from sprite list

outi ;Y
outd ;X ;outd, HL is back on Y, to dump same X,Y on next hardware sprite
out 98
out (c),a
add 4

outi ;Y
outi ;X ;this time inc HL
out 98
out (c),a
add 4

dec e
jp nz, the loop

I don't know, the NES with 8x8 sprites need to set 4 times Y X for 16x16?
With this engine, set one Y X per colorsprite and at no additional penalty shameless animate from endless pattern.

I feel many MSX2 projects stalled because messing with all the thoughts resulting from color quirk.
This reminds me of the green beret demo.

p.p.s.
Trying to cut the workload in halve: I end up with this path:
First I think it works, then multiple ideas to prevent ghost patterns,
and in the end it is all the same blinking colorcopy woes again.

One easy way to reduce workload is remove the "64k pattern" feature and go 2k pattern.
This disables diagonal scroll in screen 7 (the starting idea).

But again I end up with this idea: must afford colorcopy.

By PingPong

Prophet (2821)

PingPong's picture

13-08-2012, 23:26

hit9918 wrote:

I got another test idea:
is set-adjust able to stretch the display in the middle of a scanline?
If yes, if a scanline can be broken to pieces, then the model "delay all display at start of the scanline" was wrong.
Instead, it is some more functional (typical for hardware) way that in every cycle calculates "the X for display is the beams X getting added the adjust value".

i think no. for me it's more logical to think to a delay the display model at scanline start. But also i think no one tryed to change multiple times the adj reg during a scanline.

hit9918 wrote:

And this would mean the DMA slots get moved immedeately when writing adjust register.
In the "delay counter" model, the slots would move after next horizontal blank.
Another test idea:
Is always the whole tail of a blit wrecked, or maybe after some lines things are ok again?
If always the whole tail is wrecked, this speaks for the "sync on command start" theory.

some time ago, changing adj at every vblank during vdp execution, i saw the 'garbage'. it does appear in the form of random pixel not of the expected color. I've expected to see this error at regular intervals of time. Instead errors are not regular and too often on screen. maybe they were 20-30 errors for an entire screen (the command was a logical copy moving 100000 pixels and ran for 1 second )

By hit9918

Prophet (2551)

hit9918's picture

13-08-2012, 23:57

Were the error pixels outside the blit area?

By PingPong

Prophet (2821)

PingPong's picture

14-08-2012, 10:30

hit9918 wrote:

Were the error pixels outside the blit area?

cannot say. the command was a full screen command.... :-(

By ARTRAG

Enlighted (5689)

ARTRAG's picture

14-08-2012, 17:25

hit9918 wrote:

This somehow got me into an idea for a MSX2 engine.

Using screen 7. Because of the screen 8 sprite color problem, screen 7 is the top game mode.
screen 7 scroll 1 pixel per frame like screen 8.
I hope emu is right and set adjust still works in same range as screen 5, else speed problem.

Then, in about 150 rasterlines dump MSX2 sprites, all color AND pattern Big smile

So you could add vertical roll, and the sprite dump can flee from the rolling screen 7.

This means you get:

diagonal scroll in the extra hires screen 7 that the sega mega drive forum does envy.
and have sega master sprites with 64k sprite pattern! why, because all sprite vram gets dumped.
after the dump, got 100% cpu of a C64 left Big smile do not complain Tongue

The sprite engine can be used independantly of the screen 7 idea.
The sprite list is pointerarray pointing to a struct like this:

Y X 16bit_P 16bit_C

16bit pattern pointer, 16bit color pointer. whoops.

example pattern dump:

pop hl ;next from sprite list
inc hl ;skip Y
ind hl ;skip X
ld e,(hl) ;P lo
inc hl
ld d,(hl) ;P hi
ex de,hl
32 times outi
dec a ;sprite count
jp nz, the loop

SAT dump:

pop hl ;next from sprite list
outi ;Y
outi ;X
out 98 ;dummy color. in blank area should not be too fast for VDP.
out (c),a ;8 bit pattern pointer. do ld a,0 before the loop.
add 4 ;just increment pattern pointer. because pattern dump goes linear with sprite list just like SAT.
dec e ;sprite count
jp nz, the loop

for reverse flicker with POP instruction,
need to maintain a reverse version of the sprite pointerarray.
If you don't want that, do the copy codes MSX1 ringbuffer style.

The games will typically look like this:
Masses of sprite pattern. A tendency of shameless animation as the coder does flip patterns at zero speed penalty.
Masses of sprites without "MSX2 typical" flicker.
Because e.g. Undeadline does flicker caused by doing strange multiple SAT caused by wrestling the colorbyte quirk, not by 9th sprite.
You code less but get more performance!

p.s.
one could give up the ability of single linecolor sprites and then get more easy two-sprite colorsprites.
The two-sprite colorsprite then is like one rock solid sprite from programmers point of view.

Changes:
In pattern and color dump, just double the amount of outi. Two hardware sprites filled per one sprite list entry.

Then this SAT dump:

pop hl ;next from sprite list

outi ;Y
outd ;X ;outd, HL is back on Y, to dump same X,Y on next hardware sprite
out 98
out (c),a
add 4

outi ;Y
outi ;X ;this time inc HL
out 98
out (c),a
add 4

dec e
jp nz, the loop

I don't know, the NES with 8x8 sprites need to set 4 times Y X for 16x16?
With this engine, set one Y X per colorsprite and at no additional penalty shameless animate from endless pattern.

I feel many MSX2 projects stalled because messing with all the thoughts resulting from color quirk.
This reminds me of the green beret demo.

p.p.s.
Trying to cut the workload in halve: I end up with this path:
First I think it works, then multiple ideas to prevent ghost patterns,
and in the end it is all the same blinking colorcopy woes again.

One easy way to reduce workload is remove the "64k pattern" feature and go 2k pattern.
This disables diagonal scroll in screen 7 (the starting idea).

But again I end up with this idea: must afford colorcopy.

Interesting, please detail more...
If you want I can pass you the source for the green beret demo and its screen 8 variants and the compiling tolls

By hit9918

Prophet (2551)

hit9918's picture

15-08-2012, 19:18

More detail, well, it started with this idea, when a doublebuffered screen 7 does roll vertical, it needs all 128k vram, and sprite data needs to flee into invisible area. So every frame copy all sprite data including patterns.

This gives quirkfree console sprites with 64k pattern. Pattern "as much as RAM or ROM can hold".
And the cpu left is like the beret turrican C64, but you already got a hardware sprite multiplexer.

Even when not doing the big patterncopy, I again end up saying that the least thing to afford is full colorcopy. Else, end up with unsolved partial color update rocket science, project canceled or "flicker for no reason" like undeadline.

By hit9918

Prophet (2551)

hit9918's picture

15-08-2012, 19:48

I just got another one:
So now that affording colorcopy gave you normal console sprites, get 1,3,7,15 color sprites all in one game without headache. I think things like 7 color sprite were avoided because of problems with odd SAT positions.

Method, 4 sprite pointerarrays. Copied one after another to SAT:

1 array for 15 color sprites
1 array for 7 color sprites (3 mono sprites combined)
1 array for 3 color sprites
1 array for mono sprites.

First copy the 15 color sprites, so they are 4-aligned in SAT.
After every 7 color sprite copied to SAT, copy one from the mono array.
If out of mono sprites, paste a dummy hole. This keeps the 7 color sprites aligned in SAT, no bad sprites appear when flicker.
Then come the 3 color sprites being aligned.
Then comes rest of mono linecolor sprites.

It will be itching to get this stuff in same order for reverse copy or ringbuffer rotate.
So first create a linear array view and then use reverse copy or ringbuffer rotate on that one.
The linear array needs to be calculated only in frames where sprites were added/removed.

Example situations of flickerfree stuff on one scanline:

a 3 color player, two badass 7 color enemies.
a 7 color player, a linecolor bullet, two 3 color enemies.

Done that, all other coding is fire-and-forget and easyer game design.

By hit9918

Prophet (2551)

hit9918's picture

15-08-2012, 20:02

I got another one Smile

Draw player swords with the cpu on port 98 while MSX2 blittercopy scroll. Every frame there is some area where blittercopy does read, can't paint there. And maybe some neighbour area of next frame also is taboo, details would need to be sorted out.

Player swords are thin, need not much cpu time.
These swords would flicker permanently, because blitter permanently ploughs thru the screen.
Except getting assisted by a hardware sprite in the frames where they get prevented from appearing.

This could keep a lot of sprite load off the scanline in horizontal shooters.

Page 6/10
1 | 2 | 3 | 4 | 5 | | 7 | 8 | 9 | 10
My MSX profile