Jump to content
Xtreme .Net Talk

Frasse

Members
  • Posts

    13
  • Joined

  • Last visited

Everything posted by Frasse

  1. I just took another look on your code. DAMN it's fast! It's fast on big areas aswell. Nice! Anyways, your code showed me that it was possoble to do nice fast graphics using a bitmap that fills the whole area, an bitmap that is drawn on the control Graphics surface each time it should be updated. I thoght that this would be too slow, so I update small areas instead resulting in more GDI+ operations. So I guess I'll be trying that out ;).. /Frasse
  2. Thank you man! A moment ago I thoght most subscribers to this forum avoided complicated issues, but now I see that there are some guys out there who knows what they are doing. ;) No offence everyone else out there :rolleyes: This is exactly the kind of information that is usefull ;). Now I might be able to reduce ALOT of stupid GDI+ operations. Purely spontaniously I'd say that I just had a good idea, which I just deleted since it still had too many GDI+ operations. I was hoping that I could get away with just creating a bitmap and draw it on the control Graphics surface each frame. But now I realise I need to put the old one back aswell. So I'll see about how to solv this the best way soon. I'll post my upcomming solutions.. Thanks /Frasse
  3. Atm I'm manipulating an area of 300x300 size, it's too slow on my PII 733Mhz. When isolating the issues, for sure it takes time to do the GDI+ based operations: - Paste back the last saved Bitmap - Cut out the new one - Create a new Bitmap based on the cuted - Paste the modified on the cut out area But between cuting out the new and pasting the modified this is what i need to do: - Iterate thru Y-Axis (300 times) - Iterate thru X-Axis (300 times) (Following code runs 300*300 times per frame) - Read 2 arrays (_XMap and _YMap) - Read source bitmap pixel (Guess you can call this an GDI+ operation) - Write dest bitmap pixel (This might also be a GDI+ operation) - End of X-Axis iteration - End of Y-Axis iteration For sure it could not take too much time reading those lookup arrays which is defined as Private _XMap(,) As Integer (_YMap is naturally equaly defined). So I guess that it's those Bitmap.Getpixel and Bitmap.Setpixel that takes too much time in this innerloop. Any suggestions? I'm about to look more into dubbelbuffered GDI+ to see if there is any way I can access the Bitmap object data as an array instead of using those methods. Btw. Please read my other inlays (linked in the first post of this thread) to understand more of what I'm trying to acomplish. Also we wouldn't like to have them OS X guys laughing at us because we can't add nice features to our most extendable OS? I have one of them with his OS X LaunchBar featured Mac on the other side of my desk, he is an musician :p.. /Frasse
  4. Yeah you did ;), but I miss understod your code at first. But after taking a second glance at it I see that it was just right. Also since I create the Dest Bitmap out of the Source there is a lot to gain here. Thanks.. Still, I wan't to know if there is more to gain. Take a look at my other postings regarding this matter from different views: http://www.xtremedotnettalk.com/t74685/s.html and http://www.xtremedotnettalk.com/t74651/s.html Thanks again /Frasse
  5. Good thought, I might be able to do something out of it. Basicly what i want to do is to take the source which holds an original copy of the picture. And move the pixels around based on the remapping that the _XMap and _YMap arrays hold. So if i take the 1X1 pixel out of the source, and I check in the _XMap and _YMap table to see where the 1x1 pixel should be placed in the destination Bitmap. So if _XMap(1,1) = 3 and _YMap(1,1) = 5 the source pixel 1x1 should be on coordinate 3x5 in the destination Bitmap. Hope you get it (I'm in a hurry, GF is on me ;)) /Frasse
  6. Earlier I posted another thread in the Direct X forum http://www.xtremedotnettalk.com/t74651/s.html This question was about if it was possible to output Direct X graphics in a UserControl, and weather it is worth the effort or not. In this post I say that I don't know if the performance will be enough, I also describes the architectural solution (small explenation). Now I know that it's not possible to get decent speed out of a realtime cut, modify and paste code using bitmaps and my solution. However, I posted another thread in the VB.NET language specific forum: http://www.xtremedotnettalk.com/t74683/s.html This post is about optimizing the inner loops of the manipulation code. So at last I turn my questions to you GDI+ coders to ask if there is a better way then actually cutting and pasting Bitmaps. /Frasse
  7. Need to optimize a loop accessing an array and two bitmap objects I have the following code. It's purpose it to take a source Bitmap object, read it and manipulate it throwing out an resulting Bitmap object. This should be done in realtime since it's done while moving the mouse over an image. The code calling this method is managed, the bitmap objects are allocated as managed objects. Now I wonder how I make the best optimization of this code. It might not mean that it should be unmanaged, just as fast as possible. Private _ManipulationSize As Size Private _XMap(,) As Integer Private _YMap(,) As Integer Public Function GenerateManipulated(ByVal Source As Bitmap) As Bitmap Dim Dest As New Bitmap(Source) Dim XCo As Integer, YCo As Integer For YCo = 0 To Me._ManipulationSize.Height - 1 For XCo = 0 To Me._ManipulationSize.Width - 1 Dest.SetPixel(XCo, YCo, Source.GetPixel(_XMap(XCo, YCo), _YMap(XCo, YCo))) Next Next Return Dest End Function Thanks.. /Frasse
  8. If you have a GFX card that provides graphics acceleration, and you specify that you wan't to use hardware accelerated graphics using this card it will certainly be a relieve for the CPU provided that you use Direct X functionallity. The purpose of Direct X is to provide a single API for the coders so that they can write one set of code which can communicate with the graphcis and sound hardware independent of what functionality it provides. If the hardware doesn't support for example 3D acceleration, then Direct X will software render that graphics for you and you will still have a high CPU load. Still, as a coder you can use a Direct X 2D surface and write your own 3D engine or your own 2D graphics library and you will still have the high CPU load. So to take advantage of hardware acceleration using Direct X you must learn to use it correctly :D. /Frasse
  9. I'm thinking about writing a UserControl in VB.NET. If any of you have seen the nifty "LaunchBar" that Mac OS X uses you'll know what i mean. The thing is that this control should be a control which you can use in any Winform application, it's purpose should be like the Outlook bar. Anyway, I've been trying to write this control using GDI+ and I keep running into problems. I still don't know if the performance will be good enough. I really don't know if Direct X would solv the problem eidther since I'm doing my own manipulation of the bitmaps (based on my old school demo effect skills :D). I'm not really sure if there are any nice lens effects in the DX API, or even if it's possible to do this in a easy way with DX. Last time I coded DX was with version 5, and I really don't know if it's worth the effort relearning everything again. Also if there are better ways to optimize the GDI+ code then there would be no point in rewriting it for DX. This is how I do it atm. Startup: - Create an instance of the UserControl (called LaunchBar) - Set background image property (shadowed for my own purpose) - Add Launch Items (Images) The Launchbar keeps a: - bitmap the size of the control called _Layer - bitmap the size of the manipulation area called _LastSaved - position of the _LastSaved bitmap called _LastPos Initialize: - Background image is tiled over the _Layer bitmap - Each of the Launch item Icons are drawn on the _Layer bitmap aswell - The _Layer bitmap is drawn on the UserControl When mouse moves over the LaunchBar (MouseMove event): - Check if the _LastSaved keeps a reference (If is Nothing) to a bitmap - If so, paint it back on the UserControl where it belongs - Save the current mouse position in _LastPos and cut out the new _LastSaved bitmap (using Bitmap.Clone(Rect, PixelFormat)) - Send the _LastSaved bitmap into a method that creates a new bitmap called _Modified. The _Modified bitmap is based on the _LastSaved but the pixels are moved around to create a nifty effect. The _Modified bitmap is then returned to the caller. - The _Modified bitmap is drawn on the UserControl If there is a better way to do this, please give me feedback about it ;) /Frasse
  10. Anyway, if you have problems running your apps on others computers. Have you tried to compile your project as Releas not Debug? There is a minor chance that they have the debug runtimes but major chance they have the releas ;). Just a hint if you havn't tried it. /Frasse
  11. Actually moving up to Direct X is quite a step. Adding a dubble buffer to a GDI+ code isn't changing the whole architecture of the code, wich DX would. So it wouldn't help you if someone rewrote your game in DX because not a single line would be the same and you wouldn't understand it more then the tetris code or any other source you could get your hands on. /Frasse
  12. Before I can help you with this you must tell me what kind of scroller it is. If it scrolls in all directions for example. Next thing i need to know is what your graphics is like. If it's tiled, then how big are your tiles? If you are using the tiled technic (wich i prefer, cus it's more fun), based on the resolution of 640x480 i would use tiles of size 64x32 (I think spontaniously :p) wich would give you a 20x15 tiled screen. Also, you will need 2 backbuffers. One is the real backbuffer wich you use to prevent flickering. But the other one is a mapbuffer. This is the background of your scene. Since i guess you will have characters running around in your game, you better separate the backbuffer from the background since you don't wan't to recalculate the map each frame (huge performance loss). What you do instead is that each time your screen is scrolling into an area wich is not yet calculated, is that you actually scrolls the mapbuffer a whole tile, reset the offset to to the center of your mapbuffer, add an extra row of tiles on the edge where you just scrolled in, and start all over again. This gives you a backbuffer sized the screen buffer and a mapbuffer sized 704x512 pixels with 22x17 tiles. I'm a bit tired now so excuse me if I wasn't clear enough, but if you need help just send me a mail and I'll do my best to help you with a technic that suits your game best. /Frasse
  13. Just read you're question and tried your game. It looks nice i must tell you, amusing GFX ;) Anyway about your little problem, because i saw that it wasn't that nice when I tried a little jump with the little fellow. It's bin a long time since i did this last. So after rewriting this three times I've just figured out that I actually need to sit down and try it my selfe before giving you a good answear. But I'll tell you the basics: First - you need a "line". That is the bow that the guy should follow in his jump. This line comes from some sort of algorithm, eidther from a sinus list or from something like: V equ Velocity = Nr of pixels guy moves first fram K equ Velocity takoff = How many pixels slower he moves each frame V = V - K Y equ Y coordinate Y = Y - V I'm tired now, so this might be bull . Anyway, sooner or later K should make V negative, then the guy would start fall. This is the basic theory, check out your physics books (I've forgotten everything). Also remember that this is a game, it should not be based on real gravity (wich is boring). Play around, also remember to change Velocity based on example the speed the guy is running, how long the jump key is pressed or something else interesting. If you need more help, send me a mail and I'll try to dig out some of my old sources for you (if I have any left that is ;)). Or atleast come up with some good theory you could use and modify for your needs. /Frasse
×
×
  • Create New...