Path: chuka.playstation.co.uk!news
From: Andrew Partington <andrew.partington@harbinger.com>
Newsgroups: scee.yaroze.freetalk.english
Subject: Re: negative scrolling on homebrew map routine - need help!!
Date: Tue, 20 Mar 2001 15:18:32 +0000
Organization: PlayStation Net Yaroze (SCEE)
Lines: 79
Message-ID: <3AB774C7.6B4D8F95@harbinger.com>
References: <3AAF7BB2.B427AED3@harbinger.com> <98o38v$ij81@www.netyaroze-europe.com> <98p3qp$rms2@www.netyaroze-europe.com> <98t840$6f5@www.netyaroze-europe.com> <99057g$3ok7@www.netyaroze-europe.com> <3AB6404F.65C9AF1C@harbinger.com> <9961fn$7jl4@www.netyaroze-europe.com> <99624q$7jl5@www.netyaroze-europe.com> <9963bb$7jl6@www.netyaroze-europe.com> <997j6l$7jl8@www.netyaroze-europe.com>
NNTP-Posting-Host: manuk94.harbinger.co.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en

Hi all!

Matt Verran wrote:

> I aggree that you shouldn't be getting such a high Hsync value.  Like you
> said i'd expect it to be under 100.
>
> Hmmm I'd try eliminating all the 16bit textures for starters.

Wouldn't that affect the drawing speed with regard to the texture cache?  I
thought that the optimum block size for 16bpp graphics was 32*32  (which is not
in the demo I posted BTW, I have another version where all my blocks are of size
32*32 but zoomed out to give the appearance of a map made of 16*16 blocks, I
didn't post that one because it currently doesn't look as nice when everything
is zoomed out ;).  This does give a small speed increase, but doesn't get me
under 100 HSyncs)   If I moved to 8bpp wouldn't I need my blocks to be sized
32*64 to be optimal? (or am I misunderstanding something?)  This is the reason I
moved to 16bpp 32*32 blocks for the foreground map graphics (everything else is
8bpp).

>
>
> Are you drawing blocks even if they are offscreen maybe (maybe when they are
> really big and only a few can be seen but you're still sorting a screen full
> of small ones)?  Things can slow down quite a bit when you are scaling
> sprites up massively (more than 6 times ish).
>

err.. yes I am - but I expected slowdown from that anyway, it should be fairly
simple to reduce the amount of blocks being drawn depending on the level of
zoom.  I thought that I should sort out optimisation for the "normal" (i.e.
unzoomed) case first, then work on stuff like that later.  (there's only a 4X
zoom being done BTW)


>
> Try changing divisions and multiplications to shifts in loops with many
> itterations.

I'll have a go tonight [i'll also try Martin's idea of checking for -ve before
doing any divisions - not an optimisation measure I know but it might make the
background handler work more correctly :)] - although, like I said, removing the
mod didn't seem to help much (even though its essentially a divide, which are
meant to be slow as, (for CISC anyway...))

Last night I attempted using VSyncCallback() for the first time to attempt to
get more raster time (as explained in the Net Yaroze FAQ), but I couldn't get it
working [so I went away and had a look at some other optimisation measures
instead, none of which seemed to have much effect :( ]

I had something like:

(in my globals section of my code)
volatile int waitVSync = 0;

void MyCallbackFunction()
{
    //callback code
}

then before entering the main program loop (not every frame), I did:

VSyncCallback((void*) & MyCallbackFunction);

Where I usually call DrawSync(0); VSync(0), I replaced it with the suggested
code to change the waitVSync variable, as sugested in the Yaroze FAQ.  On
compiling/running I just got a black screen.

Do you need to register MyCallbackFunction() with VSyncCallback() every frame,
or just once?  (I was only registering it once - admittedly, I didn't experiment
very much with this, as i'm not 100% convinced i'll get a major speedup - wasn't
VSyncCallback() written just to get round a problem in interlace mode?)  And
what is the int that VSyncCallback() returns?


Cheers again for everybody's help!!

Andy