Simply impressed!

Página 5/6
1 | 2 | 3 | 4 | | 6

Por Manuel

Ascended (18744)

imagem de Manuel

20-08-2011, 21:15

That is possible, just drag it just *below* the window handle of Windows into the main window. You'll see a preview of where it will end up.

Por PingPong

Prophet (3885)

imagem de PingPong

21-08-2011, 13:23

That is possible, just drag it just *below* the window handle of Windows into the main window. You'll see a preview of where it will end up.
tryed but seem not to work. when possible i will re-try. thx

Por Manuel

Ascended (18744)

imagem de Manuel

21-08-2011, 14:05

Drag it left of where the little cross is to close it.

Por Hrothgar

Champion (479)

imagem de Hrothgar

21-08-2011, 16:39

OK, so this is what it looks like.

Screen continuously alternates between two pages, one of the two pages has the right border filled with background, the other has not, player characters are updated in the border as software sprites in both pages. And the whole bunch is undone by hardware sprites again.

img15.imageshack.us/img15/1498/nutsv.png

So, does anybody have any idea what this technique is supposed to do? I can't imagine it is sloppy coding - it's actually way too much work for that so it must have a reason.

Por PingPong

Prophet (3885)

imagem de PingPong

21-08-2011, 18:30


Have you checked your spambin lately?

thx, i've done some tests.
initially i've thought the main bottleneck was the vdp engine.
i've tryed with those configurations:
1)standard z80 @3mhz+vdp command timing real
2)standard z80 @3mhz+vdp command boosted
3)z80 @ 14mhz+standard vdp command timing
4)z80 @ 14mhz+boosted vdp

conclusion:
the main bottleneck is were there are enemies on the screen. one can think "because o BOB's handling". NO!. Because of the enemy "AI". even increasing vdp cmd speed the game does not accelerate. Instead increasing z80 speed and leaving standard vdp speed, the game gain some fps.

so the main bottleneck was the game logic.

i'm guessing if one can increase performances by re-writing in 'c'+asm the game...

Por Hrothgar

Champion (479)

imagem de Hrothgar

21-08-2011, 18:42

Interesting. So when disabling sprites the game could actually be a lot faster again (in fps and smoothness of the scrolls and players), if only for the game logic.

Por PingPong

Prophet (3885)

imagem de PingPong

21-08-2011, 18:44

Interesting. So when disabling sprites the game could actually be a lot faster again (in fps and smoothness of the scrolls and players), if only for the game logic.
no.
the game logic is the bottleneck
(or if you prefer, the z80 @ 3.5mhz is the bottleneck)

Por turbor

Champion (496)

imagem de turbor

22-08-2011, 09:47

OK, so this is what it looks like.

Screen continuously alternates between two pages, one of the two pages has the right border filled with background, the other has not, player characters are updated in the border as software sprites in both pages. And the whole bunch is undone by hardware sprites again.

So, does anybody have any idea what this technique is supposed to do? I can't imagine it is sloppy coding - it's actually way too much work for that so it must have a reason.

This 'technique' is a simple trick by the programmer to allow the software sprites to go 'into the border' . The advantage of this technique is twofold:
1) The software sprites can now be copied entirely by the code as if it was copying the blob in the visible area, thus avoiding any extra overhead that would be introduced if clipping had to be done by the software. Since the game is programmed in X-Basic and the player drawing is in the main gaming loop this overhead would quickly become quite annoying resulting in very measurable slowdown.
2) As a nice side effect the playing area now becomes smaller, thus copying of the playing area itself (when scrolling and clearing the blobs in the non-visible area) becomes faster :-)

Por Huey

Prophet (2687)

imagem de Huey

22-08-2011, 10:29

X-Basic eh! Hannibal

Por Hrothgar

Champion (479)

imagem de Hrothgar

22-08-2011, 10:44

I don't really understand those arguments, as the overhead of copying player characters over the borders is simply an integer subtraction and block-copying a somewhat narrower strip, and the faster copying due to the narrower main area also is undone when background is still painted in the hidden borders, as you can see in the screenshots above. So I'm not really convinced these techniques are necessary or even useful.

I am starting to get convinced that the block-copying capacity of VDP has been underused or underestimated back in the days. When the inefficient coding is solved (as mentioned by PingPong) and the VDP limits are raised by disabling the hardware sprites (and possibly again by a factor when you can introduce differential copying, quite doable for many floors, walls, fences and sky but probably not used in this game), I think we have a very reasonable graphics that can more than compete with other contemporary systems.

I have to say that in this game I really find the gameplay lacking with the graphics being quite OK already.

Página 5/6
1 | 2 | 3 | 4 | | 6