I posted this at the NSBasic forum without a lot of replies. I was wondering if more experienced programmers here had any thoughts.
I've been experimenting recently with graphics under NSbasic 6.5.3b on my older model H/PC
(a MobilePro 780
) and was wondering if anyone had any suggestions for improvement or some other technique I haven't seen yet. I can't use AspriteCE and my system dosent support GAPI.
Background: I'm working on a small Single-player RPG similar to the old Ultima series. I have a rough but working map editor and some basic animation done, and will be working on a sprite editor soon. Something like the link below is what I'm eventually aiming for.
http://www.consoleclassix.com/gameinfo_ultimaexodus_nes.html
I originally intended to use the BitBlt API function for all graphics, it's fast and does exactly what I need and I even worked out a method of triple buffering to reduce flicker on redraws. Everything works fine until you tap on the screen. This pulls the picturebox.picture to the front which, since I'm going through the Picture Box's hDC instead of .picture property, results in a grey box in place of the graphics. Even trapping everything I can think of and re-bliting the image results in an annoying flicker, just what I'm trying to avoid. Also you can't save a bitblt'd image to a file as SaveImageToFile saves out an empty .bmp.
Under VB
(not eVB that I know of
) you can avoid these problems with Bitblt by using the picturebox.picture=picturebox.image command but neither the NSBasic picturebox nor MS's picturebox support the image property. I also tried Bitblting directly to the Output window bypassing pictureboxes entirely but it behaves the same.
So I decided to use the normal picturebox functions. This works well enough but is slow.
At the moment I have a background picturebox off-screen that gets copied through the hbitmap property to a compositing picturebox where I perform any updates to sprite locations, then the whole thing gets copied to the user's display. It works in effect like the triple-buffered system I was using for Bitblit but is several times slower.
A wrapper of some sort around Bitblt that ties it into the regular system of controls and properties would be ideal. I realize that's not a trivial task.
So if anyone has any suggestions on speeding things up, or getting BitBlt to work or even how to completely trap screen tap events, I'd appreciate hearing them. I may try resaving all the graphics as 256 color bitmaps and see if that's a worthwile tradeoff.
I attached a current screenshot of the map editor, still needs lots of work.
Thanks, Carl.