(Link to AcmlmWiki) Offline: thank ||bass
Register | Login
Views: 13,040,846
 Main | Memberlist | Active users | Calendar | Chat | Online users
Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album 		04-23-23 03:03 AM
0 users currently in Programming.
Acmlm's Board - I3 Archive - Programming - C# editor problems.. New poll | |
Add to favorites | Next newer thread | Next older thread
User Post
Euclid



 





Since: 11-17-05
From: Australia
hmm...

Last post: 5913 days
Last view: 5907 days
Posted on 02-12-06 07:38 AM Link | Quote
I'm writing an editor in C#, I can get it to draw but it's just plain slow (no i'm not using setPixel, that makes it 10x more slower)

Currently I've decompressed the gfx, and got all those 8x8 tiles loaded into bitmaps using bitmapdata, then displaying them into a picture box with drawimage (which is 512x512), but it takes a few seconds (instead of say, instant) to just run through the paint function once.

Am i doing something wrong or is C# just too slow to build editors from? Anyone got good tips?
||bass
Administrator








Since: 11-17-05
From: Salem, Connecticut

Last post: 5908 days
Last view: 5907 days
Posted on 02-12-06 03:21 PM Link | Quote
It has nothing to do with C#, it's probably that you're doing unnecissary work in your draw function. Are you painting ALL the tiles or only the ones you actually need to paint (onscreen ones)? Something to look into.
Dan

Purple Leever


 





Since: 11-18-05

Last post: 5916 days
Last view: 5907 days
Posted on 02-12-06 05:31 PM Link | Quote
How exactly are you doing the drawing? I am assume you are using an 'unsafe' method to draw the tiles (manipulating the bitmap's data directly)?
sloat



 





Since: 11-18-05
From: Delaware, US

Last post: 6010 days
Last view: 6010 days
Posted on 02-13-06 12:22 AM Link | Quote
MSDN says you can get a performance boost using a CachedBitmap class and the Graphics:: DrawCachedBitmap method. But you might not be able to use it depending on your situation.

There's no doubt that GDI+ is slower than regular GDI or DirectX, but it still shouldn't be that slow. Once you've got it loaded and ready to go, it should draw almost instantly. The only time I've ever had something go very slow was when I was fooling around with the automatic gamma correction and alpha-blending. Still, it was rendering a 550x320 bitmap with about 10 sprites at about 6 or 7 frames per second.

(edited by sloat on 02-12-06 11:22 PM)
Euclid



 





Since: 11-17-05
From: Australia
hmm...

Last post: 5913 days
Last view: 5907 days
Posted on 02-13-06 06:57 AM Link | Quote
The only time i'm using the unsafe to draw the tiles is on first load.

And yes i'm painting every single 8x8 tile on the 512x512 display everytime (should i really be painting the ones i need only? If that's the case I'll have to redo my code, but how should i know which bits are offscreen and needs to be repainted?)

I think setting a palette on each 8x8 tile on every paint before using drawimage onto the picturebox might also have something to do with the problem though
||bass
Administrator








Since: 11-17-05
From: Salem, Connecticut

Last post: 5908 days
Last view: 5907 days
Posted on 02-13-06 08:50 AM Link | Quote
Originally posted by Euclid
The only time i'm using the unsafe to draw the tiles is on first load.

And yes i'm painting every single 8x8 tile on the 512x512 display everytime (should i really be painting the ones i need only? If that's the case I'll have to redo my code, but how should i know which bits are offscreen and needs to be repainted?)

I think setting a palette on each 8x8 tile on every paint before using drawimage onto the picturebox might also have something to do with the problem though
Continuously repainting a 512x512 bitmap is going to kill you overall in ANY language.

Consider:
  • Only repainting what is necissary. (You use MATH for this. Try to remember some from school.)
  • Set the palette for each tile ONCE and then storing it in memory. Don't redo unless necissary.
  • Remember, use memory buffers. If you can do a peice of work once and store it in memory, DO IT. One of the most important aspects of good programming is not doing redundant work.
    		•
    Guy Perfect









    Since: 11-18-05

    Last post: 5909 days
    Last view: 5907 days
    Posted on 02-13-06 01:40 PM Link | Quote
    As a rule of thumb as far as optimization is concerned, speed quality is inversely proportional to memory usage quality. You can either use little memory and make it slower, or make it really fast and use more memory.

    Computers have migs and megs of memories (as Strong Bad put it), so don't be afraid to go for the high speed, high memory (sounds directly proportional if you put it that way) route. Your users will thank you.
    Euclid



     





    Since: 11-17-05
    From: Australia
    hmm...

    Last post: 5913 days
    Last view: 5907 days
    Posted on 02-14-06 09:04 AM Link | Quote
    Thanks, I got that problem fixed.

    How about changing palettes? I'm sure having 20 or so different tile bitmaps just for each palette is not a good idea... or is it?

    I wonder if it's possible to use pointers to point all the palette of 8x8 tile to a common piece of ColorPalette so all i got to do is change that to change palette.
    ||bass
    Administrator








    Since: 11-17-05
    From: Salem, Connecticut

    Last post: 5908 days
    Last view: 5907 days
    Posted on 02-14-06 11:51 AM Link | Quote
    Originally posted by Euclid
    Thanks, I got that problem fixed.

    How about changing palettes? I'm sure having 20 or so different tile bitmaps just for each palette is not a good idea... or is it?

    I wonder if it's possible to use pointers to point all the palette of 8x8 tile to a common piece of ColorPalette so all i got to do is change that to change palette.
    Why don't you write your own specific tile and palette classes for just that purpose. Just inherit from (or encapsulate, up to you) the origionals.
    Add to favorites | Next newer thread | Next older thread
    Acmlm's Board - I3 Archive - Programming - C# editor problems.. |


    ABII

    Acmlmboard 1.92.999, 9/17/2006
    ©2000-2006 Acmlm, Emuz, Blades, Xkeeper

    Page rendered in 0.018 seconds; used 384.73 kB (max 475.81 kB)