Cursor flicker and lots of views

[Doan Sephim]

(Thread split from 'Maximum Size of Views')

I have some massive Prop VIEWs in one room and multiple Act VIEWs in another. In both cases it slows the game down. I might be willing to be ok with that (particularly because increasing the dos box cycles is sufficient to speed up those sections). What I do not like, and wonder if anyone can help me with is whether I can stop my cursor from flickering while over these VIEWs?

Thanks

[gumby]

I never did determine what the max size of view was, however in 120 Below, I also suffered from flickering cursor issues which I never did resolve.

I'm guessing you've already reviewed this thread: http://sciprogramming.com/community/index.php/topic,212.0.html

Are the props animated?  If not, can you use the 'dropped view' technique?

[Doan Sephim]

In one room they are animated, in the other the props are not moved, but they change position in the doit method

[gumby]

I've got an idea on this one.  It's a long shot & I need to do a proof-of-concept first, but here are my thoughts:

How about using text to draw your pictures?  First, create a font resource that consists of characters which are one pixel high/wide with a height of the overall font of 1 pixel.  Then you basically 'draw' your view with this font, changing the color appropriately.  Using the Display() command & dsSAVEPIXELS property you should be able to place, and then later remove, your 'view'.  The only painful part is drawing the image - you would need to make different calls to the Display() command every time your pixel color needed to change and keep track of your x/y positions.  On the upside, you could put your image data into a text resource & avoid some potential heap issues.

On the surface, I think this would eliminate the flickering at least in the scenario where the 'view' isn't moving.  Not sure how it would behave if it's animated with multiple Display() calls in a doit.

I'll try to put together a working demo this weekend.

[gumby]

I hadn't considered the issue of priority.  Using a Display() command it seems to have a priority setting such that it's always in the background.  So when the ego is placed in the same location, it always hides the displayed text.

If I draw the text in a new window port, I can effectively always have the drawn text to be in the foreground or the background.  So that's slightly better, but still pretty limited.

[gumby]

Starting to make progress.  Instead of creating a font with a single pixel and drawing each pixel in the view, I'm taking a different approach.  Create a font with characters the same size as your view.  Then create as many font characters as colors (up to 16).  Each character consists of which ever colors are 'turned on' for our view.

Then you call as Display() up to 16 times, using the same x/y coordinates each time.  Since the font drawing is sensitive to transparent pixels, we are basically 'layering' the image, drawing one color at a time.

As a test I'm going to recreate the template game ego view, but with leveraging fonts.

[gumby]

I've uploaded (and temporarily attached here) a demo game of this solution.  It display/hides a dozen ego images, created by using font resources.  No cursor flicker at all.  Heap impact is small, it only costs roughly 2000 bytes to display a dozen ego images.

I consider this solution to be an improvement on the 'dropped view' technique, but with the added functionality of being able to remove the view from the scene & restore the original background pixels.

It's a bit slow in drawing, noticeable when you attempt to do an animation loop in a doit() method - the image itself flickers pretty badly.  If you don't need 'view-like' animation (walking, etc), and more of just say 'picking up and putting down' inventory objects or something similar, this should work just fine.  The other limitation is that currently the images are always displayed in the background.

If this proves to be useful, I may create a utility that will convert a view into font resource appropriate for leveraging this solution.  This by far was the most painful part of this solution, having to split a view out by color.  There is a workaround that I was able to find:  when you copy/paste a view into a font resource it will only preserve the black pixels.  So you can modify your view, making the target color for the font black, copy/paste, then move on to the next color, removing all the previously black pixels from the view.

I created a new class called TextView to handle all the dirty work.  To use it, include it in your room script, create an instance...

Code: [Select]

(instance ego1 of TextView
(properties
xPos 40
yPos 40
fontNum 10

silhouetteChar "H"
silhouetteColor clBLACK

frame1char "A"  frame1color clBLACK
frame2char "B"  frame2color clSILVER
frame3char "C"  frame3color clGREY
frame4char "D"  frame4color clRED
frame5char "E" frame5color clMAROON
frame6char "F" frame6color clNAVY
frame7char "G"  frame7color clBLUE
)
)

Then just call the show/hide methods in your room script:

Code: [Select]

       (if(Said('hello'))
            (ego1:show)  
        )

        (if(Said('goodbye'))
            (ego1:hide)
        )