Demon Arena [Updated April 18th, 2015]

http://imageshack.com/a/img538/9758/YUZpFq.gif

This is actually a re-writing of a VB6 screen saver I created years ago. You can download the source for that one here. I no longer use VB6 so that one is pretty much stagnant. I've chosen to re-write it VB.Net rather than try to wrangle with that one.

Simply run the application and click any of the three menu items to add creatures to the Form. The creatures would then engage each other in projectile fights to the death until creatures of only one type remain.

For now there are only three different creatures but I'll be adding more over time. I'll also be adding new effects, and abilities for the creatures and eventually, sound, just like the VB6 version.

Additional credit

• The community members of ZDoom.org for the creation of those sprites.
• ID Software for the creation of Doom which ZDoom is based on.

DemonArenaV1.0.0.0 Source.

Note: You need VS2010 or later to open.

Update: Version 2.0.0.0

• Added three new monsters.
• Added glow effects to projectiles.
• Added explosive projectiles, explosive physics and area of effect damage.
• Added multiple attack types to certain monsters. The Creature base class now allows to define multiple attack types for derived monsters.
• Moved the arena from the Form to a control. Inherits from Control and implements IArena.
• Added a teleport fog which appears when new monsters are spawned.
• Added explosion animation when explosive projectiles explode.
• Added an Anomaly base class for creating simple entities. The teleport fog and explosion inherit from this class.

Additional credit

• Jemidiah for helping me with the math that powers some parts of the engine.

I'll leave the original version up as well since its much simpler in comparison to this one.

DemonArenaV2.0.0.0 Source.

Update: Version 2.1.0.0

• Added two new monsters.
• Minor code changes.

Note: This is the last version that can work without XNA.

DemonArenaV2.1.0.0 Source.

Update: Version 3.0.0.0

• Added two new monsters.
• Added a high performance XNA renderer. It will no longer slow down when there are too many entities in the arena.
• Added dash defense for some creatures. Implemented in the Creature base class so every creature has the potential to use it.
• Added dash blur for creatures that are dashing.
• Added random spawning. This is configurable. You may configure ratios for how much of a particular creature will spawn as well as a duration between spawns.
• Added NonAnimatedEntity base class which can be used to create entities that have no animation frames. The dash blur is implemented via that class.
• Both NonAnimatedEntity and Anomaly based entities can fade out. The teleport fog now fades out.

Additional credit

• dday9 who's XNA scroll demo showed me how to use XNA to render to a Control as well as how to convert GDI+'s Bitmap to a Texture2D.

IMPORTANT
This version utilizes XNA 4.0 so in order to be able to run this in the IDE you would need to install XNA. If you're using Visual Studio 2010 then I recommend you install the XNA Game Studio 4.0. This may not work with Visual Studio versions other than 10. If you're using a later edition of Visual Studio then I recommend installing the Microsoft XNA Framework Redistributable 4.0.

The redistributable will provide the components but for some reason when you start new projects, the IDE doesn't list the assemblies if you're trying to add references to them in a new project so you cannot develop new XNA applications with just the redistributable. You would need the whole Game Studio package.

DemonArenaV3.0.0.0 Source.

Update: Version 4.0.0.0

• Added a new monster.
• Monsters now implement the IDemon interface.
• Added ComplexCreature base class which allows use to define creatures with a great degree of flexibility with respect to their behavior. The Afrits and the DarkCardinal creatures are defined using this base class now.
• Added the ability to resize the arena on the fly using the "+" or "-" key.

Note: Some things may be broken in this version. The random spawner hasn't been rewritten to consider ComplexCreature derived monsters so it may not spawn the new monster and the reworked Afrits or it may throw exceptions. It remains untested.

DemonArenaV4.0.0.0 Source.

Update: Version 4.1.0.0

• Added a new monster.
• Random Spawner now works with ComplexCreature based monsters.
• Minor code changes such as the addition of a couple ECMD(Entity command) procedures to the ComplexCreature base class in order to facilitate melee type attacks.

DemonArenaV4.1.0.0 Source.

Update: Version 5.0.0.0

• Added two new monsters.
• All sprites are now rendered with their original aspect ratio.
• Implemented new entity commands and functions for use in creature definitions.
• Fixed bug where Lost Souls would repeat their dying frames without dying when caught at the edge of the arena.
• Implemented global variables for use in creature definitions. It will allow more complex behaviors to be defined. For example, Spirits now swarm a single target at a time.
• Made a few stat changes to some creatures.
• Iron Lich, Wizard and Spirit creatures now inherit from the ComplexCreature class.
• Fixed bug where the application crashes when run on a PC where the graphics hardware is low end.

DemonArenaV5.0.0.0 Source.

Update: Version 6.0.0.0

• Added a ChangeLog text file to the DemonArena project. It would allow me to log changes as I make them. That's why this log is so much more detailed.
• Increased Dark Cardinal's rocket damage.
• Added some comments to code in the Arena class.
• Minor code changes: Altered the EntityCollection class and how its used within the Arena class.
• Minor code changes: Made collision detection slightly more efficient.
• Minor code changes: Made XNA renderer slightly more efficient by caching Texture2D objects to Sprite objects instead of doing look-ups based on string keys.
• Fixed bug where the XNA renderer would crash when the GraphicsDevice was lost. Changing the resolution while the app was running was one such way to cause the crash.
• Decreased time ArachNorb's takes from preparing an attack to the actual attack.
• Fixed bug in loop implementations of creature defininition execution where the loop would go one extra iteration.
• Random spawner's maximum number of spawns per creature changed from 20 to 100.
• Made PurpleAfrit more formidable. It attacks more frequently, it stays longer in its dashing attack and it selects a new target if it still has dash time instead of stopping. It also has a greater chance of executing the dash attack.
• GetSprite now performs dictionary look-ups instead of a linear scan when retrieving sprites to render. However, linear look-ups are performed when sprites are requested for the first time.
• Creature's definition execution engine can now execute multiple states concurrently. This makes more complex creature behavior possible. This is the most significant change of this version.
• Added entity commands for changing creature alpha value.
• Entity commands in creature definitions are now executed through the Action class rather than the Delegate class. It would improve performance of the definition execution engine as Invoke is much faster than DynamicInvoke.
• The Wraith now inherits from the ComplexCreature class. It also uses the new capability of the definition execution engine to execute states in parallel in order to implement its new special ability.
• Some DefinitionExpression derived classes now implement fields instead of properties since accessing fields are faster. The RenderInfo class also use fields instead now.
• XNADrawImage now passes Rectangles by reference instead of by value.
• Removed LINQ filtering when cycling entities in RefreshXNA.
• Made the selection of targets by creatures more efficient by not recreating a list of potential targets every time a call is made to select a target.
• The Size property of the ComplexCreature, Creature and Projectile classes were made more efficient by moving scaling calculations out of the property. Scaling is now done only when the entity's sprite has been changed and the value cached to a private field.
• Changed SpriteBatch sorting mode from Immediate to Deferred. Deferred according to various online sources is supposed to be more efficient in XNA 4.0.

DemonArenaV6.0.0.0 Source

Hi,
I noticed you had a thread about this getting slow, just as a suggestion, look into DoubleBuffering. of the form and your custom arena: http://msdn.microsoft.com/en-us/libr...v=vs.110).aspx

it has always helped me smooth out things, although I have only ever used it on forms and flowlayoutpanels :)

Quote:

---

Originally Posted by bensonsearch

Hi,
I noticed you had a thread about this getting slow, just as a suggestion, look into DoubleBuffering. of the form and your custom arena: http://msdn.microsoft.com/en-us/libr...v=vs.110).aspx

it has always helped me smooth out things, although I have only ever used it on forms and flowlayoutpanels :)

---

The one currently there doesn't suffer. I've since added glows effects to it and GDI+ is beginning to buckle under the strain of having to do too many blend operations. It has nothing to do with double buffering at all. GDI+ is not hardware accelerated so you're going to take a severe performance hit when you start blending hundreds of images on a surface.

I've since mitigated the performance hit by cutting the number of times blit operations have to be performed to render glowing projectiles in half. But there are a few other effects I plan on putting into this and soon GDI+ won't be enough. Currently I'm thinking of switching to plain old GDI for blit operations since GDI is fully accelerated on Windows XP and blit operations(BitBlt, StretchBlt, AlphaBlend) are accelerated on Win7. I really want to avoid anything based on DirectX like XNA or SlimDX since that would require others to download dependencies to get this to work.

This goes way past my experience or even remote knowledge, GDI and the like is just beyond me, never needed them but wished I could make something (always wanted to make a doom like game, soooo beyond me). all the "animation" I have in my programs is things like sliding or a custom button that shrinks then expands back when pressed. both basic and not very complex, just images and timers lol

I will keep an eye on this though as it was at least fun to watch them jump around the screen :) ps do they actually kill each other? it looks like they do

Quote:

---

Originally Posted by bensonsearch

ps do they actually kill each other? it looks like they do

---

Yes they do, via their projectiles. The projectiles of one type damages monsters of a different type.

Quote:

---

Originally Posted by bensonsearch

This goes way past my experience or even remote knowledge, GDI and the like is just beyond me, never needed them...

---

You have to know GDI in order to make custom drawn controls in VB6 which is how I learned it.

I tryed to open the sorce in visual studio 13/windows 8.1 and visual studio crahes just as it opens the source, no error....

Quote:

---

Originally Posted by evo74

I tryed to open the sorce in visual studio 13/windows 8.1 and visual studio crahes just as it opens the source, no error....

---

Is it possible you can try it using either VS2010 on Win8.1 or VS2013 on Win7. I use Win7+VS2010 so one of these differences is causing problems. I have neither Win8 or VS2013 to test it myself.

Cool! Good job on this, ima peek a little bit in the source code tommorrow haha.

Maybe u actually should consider using directX, just compile to x86 and include DLL's in root folder of the
Exe no need to download anything tested this on a few pc's. Not 100% sure.

Updated. See OP.

Updated. See OP

Updated OP to include link to the VB6 version.

Updated to version 3.0.0.0. See OP.

my goodness, you may as well start on an actual game now like doom :) i would so play that hehe, looking good!

Quote:

---

Originally Posted by bensonsearch

my goodness, you may as well start on an actual game now like doom :) i would so play that hehe, looking good!

---

I've been trying to come up with an interesting way to turn this into a game but so far, I haven't been able to come up with anything solid. The simplest game would be a betting game where you place bets on which species would win if a select combination were placed in the arena. Another idea I have is to give you a set of creatures which you can put in the arena to fight for you and if they win, you get money which you can use to power them up by buying hit points or attack strength etc. I've have not really settled on the best way to make this into a game. Another idea is to give the player a unique entity which he can control via the mouse so he can fight in the arena with it. Its surprisingly difficult to come up with a good idea to "gameify" this.

i like the idea that you can win money and spend it to boost things, im a fan of RPG type games. would need more background to it though like story and where do you go with it lol. hmmm

An issue that I have with the code(I haven't got to fully look at it yet...) is that it appears to use a timer for the game loop. You should really have a dedicated game loop, I personally use Threading so that it doesn't tie up the GUI thread:

Code:

---

    Private game_thread As Threading.Thread

    Private Sub Form1_FormClosing(sender As Object, e As System.Windows.Forms.FormClosingEventArgs) Handles Me.FormClosing
        quit = True
    End Sub

    Private Sub Form1_Load(sender As Object, e As System.EventArgs) Handles Me.Load

        game_thread = New Threading.Thread(AddressOf GameLoop)
        game_thread.Start()

    End Sub

    Private quit As Boolean = False
    Private Sub GameLoop()

        Dim s As New Stopwatch
        s.Start()

        'Update
        'Draw
        'Render

        'Loop
        While s.Elapsed <= TimeSpan.FromMilliseconds(16.6)
            Application.DoEvents()
        End While

        Console.WriteLine(s.ElapsedMilliseconds)

        s.Stop()
        If quit = False Then
            game_thread = New Threading.Thread(AddressOf GameLoop)
            game_thread.Start()
        End If
    End Sub

---

The stopwatch is a high precision timing instrument if the computer will allow it to be one. Otherwise, if the computer cannot handle a high precision timer, then it defaults to the same accuracy as a regular Timer. Set the frames per second to 60(aka 16.6 milliseconds) if you live in the US or 50(aka 20 milliseconds) if you live in the UK. The reason for this is because the refresh rate for the monitors is 60 in the US and 50 in the UK.

Updated to version 4.0.0.0. See OP

Quote:

---

Originally Posted by dday9

An issue that I have with the code(I haven't got to fully look at it yet...) is that it appears to use a timer for the game loop. You should really have a dedicated game loop, I personally use Threading so that it doesn't tie up the GUI thread:

Code:

---

    Private game_thread As Threading.Thread

    Private Sub Form1_FormClosing(sender As Object, e As System.Windows.Forms.FormClosingEventArgs) Handles Me.FormClosing
        quit = True
    End Sub

    Private Sub Form1_Load(sender As Object, e As System.EventArgs) Handles Me.Load

        game_thread = New Threading.Thread(AddressOf GameLoop)
        game_thread.Start()

    End Sub

    Private quit As Boolean = False
    Private Sub GameLoop()

        Dim s As New Stopwatch
        s.Start()

        'Update
        'Draw
        'Render

        'Loop
        While s.Elapsed <= TimeSpan.FromMilliseconds(16.6)
            Application.DoEvents()
        End While

        Console.WriteLine(s.ElapsedMilliseconds)

        s.Stop()
        If quit = False Then
            game_thread = New Threading.Thread(AddressOf GameLoop)
            game_thread.Start()
        End If
    End Sub

---

The stopwatch is a high precision timing instrument if the computer will allow it to be one. Otherwise, if the computer cannot handle a high precision timer, then it defaults to the same accuracy as a regular Timer. Set the frames per second to 60(aka 16.6 milliseconds) if you live in the US or 50(aka 20 milliseconds) if you live in the UK. The reason for this is because the refresh rate for the monitors is 60 in the US and 50 in the UK.

---

Yes, I do use a single Timer for the game loop. It seems sufficient for now. Are you suggesting that I should actively seek to control the framerate ?

Yes, most definitely.

Yea, I've seen Jacob Roman talk about this a couple times. He always writes a LockFrameRate function for his games and such. But what I don't understand is why. It suggests that it's bad to let the game draw the frames as fast as it could which is essentially what I'm doing. I've thought about locking the frame rates but I haven't had a compelling reason to do so.

What will wind up happening is something that compiles perfectly on your computer will glitch up(sometime really bad) on a slower computer. Locking in the frame rate will always provide consistent performance as one step will not go forward until at least X amount of frames has passed. Without a managed game loop you can expect to tearing graphics and if your application is very physics heavy, you can see the physics render after the drawing occurs which can eventually lead to a crash. And don't get me wrong, JR is a great game programmer, however there are a few things that I don't agree on with him... one thing is that he always loops on the GUI thread where as I always loop on a separate thread.

Wait a minute, doesn't DirectX by default update the front buffer in sync with screen refreshes ? I've been reading up on locking in frame rates and its like you said, its used to avoid tearing but for some reason I've never gotten that glitch so I'm assuming that there must be some way to swap buffers faster than the refresh rate in DirectX which would explain why this can become an issue. I have to admit, there is still a lot about this that I still don't understand.

As for game loops on a worker thread.....I've actually thought about it. I almost implemented that way but ultimately decided that I'd let every thing run on the UI thread since I'd have to invoke there anyway to render to the IArena control if the game loop was on another thread. However, I've recently done some testing with regards to performance when using multi-core systems. Heavy algorithms like collision detection would benefit tremendously on multicore systems if they were threaded.

What are the other menu for next to the "Options" menu?

Quote:

---

Originally Posted by Nightwalker83

What are the other menu for next to the "Options" menu?

---

They are dynamically generated based on the creature types defined in the assembly. Each one spawns a specific type of creature.

Updated to version 4.1.0.0. See OP.

I have tried to run the latest version but get this error on startup
Attachment 114107

Quote:

---

Originally Posted by bensonsearch

I have tried to run the latest version but get this error on startup
Attachment 114107

---

Whenever you initialize the GraphicsDevice(which Niya does in the Arena class) you need to target the appropriate GraphicsProfile based on what the console(or computer) can handle. In this case, your computer cannot handle the HiDef profile. So either change it to the Reach profile or setup a Try/Catch statement to try and set up the HiDef profile and if that fails then set it to the Reach profile:

Code:

---

Dim graphix As GraphicsDevice
Try
    graphix = New GraphicsDevice(GraphicsAdapter.DefaultAdapter, GraphicsProfile.HiDef, New PresentationParameters With {.IsFullScreen = False})
Catch ex As Exception
    graphix = New GraphicsDevice(GraphicsAdapter.DefaultAdapter, GraphicsProfile.Reach, New PresentationParameters With {.IsFullScreen = False})
End Try

---

Quote:

---

Originally Posted by bensonsearch

I have tried to run the latest version but get this error on startup
Attachment 114107

---

Search for this line in the solution:-

vbnet Code:

g_xnaGraphicsDevice = New GraphicsDevice(GraphicsAdapter.DefaultAdapter, GraphicsProfile.HiDef, pparam)

It's inside the Arena class in the PrepareDevice method. Then you try changing the second to last parameter to GraphicsProfile.Reach. The line should then look like this:-

vbnet Code:

g_xnaGraphicsDevice = New GraphicsDevice(GraphicsAdapter.DefaultAdapter, GraphicsProfile.Reach, pparam)

If this works for you, all subsequent updates would use this setting.

[EDIT]

Just noticed that you double posted and dday9 answered. He's right. Your graphics hardware probably isn't advanced enough to using the HiDef profile. I would do as he suggested and wrap that call inside a Try...Catch in future versions.

ok the change to reach worked like a charm. i wish i knew all this, all i can say is AMAZING. we need to make a game from this ASAP lol.

i went as far as changing the spawn rate to every tick and each monster just 1 of each and let the chaos happen. To my shock and surprise the graphics didnt slow down at all and the memory usage stayed the same as with 1 monster on the field. CPU went up of course but thats a given.

Well done is all I can say. wish I had the ability to get my head around game programming, all I do is business apps (like to run a biz on).

here is some chaos

Attachment 114139

EDIT

I should add that most times out of many, when matched evenly the blue afrit is a great unit, next to that if in numbers the iron lich hands down :)

Quote:

---

Originally Posted by bensonsearch

ok the change to reach worked like a charm. i wish i knew all this, all i can say is AMAZING. we need to make a game from this ASAP lol.

---

Yea, I'm still thinking about a game of some sort. I haven't decided how to change this into a game yet. I want to upgrade all the monsters first by having them inherit from ComplexCreature instead of the older Creature class. I also wanna add a few more monsters too.

Quote:

---

Originally Posted by bensonsearch

i went as far as changing the spawn rate to every tick and each monster just 1 of each and let the chaos happen. To my shock and surprise the graphics didnt slow down at all and the memory usage stayed the same as with 1 monster on the field. CPU went up of course but thats a given.

---

The XNA renderer uses DirectX which is blazingly fast. I was also very careful with the handling of resources. Lessons I learned from the last one I wrote in VB6. However, there are a couple of inefficiencies. The collision detection system for one. You can see this if you spawn an excessive amount of Cacoliches. They fire a tonne of projectiles and you'd see quite a performance drop due to all the collision checks. I have to revise the collision detection system.

Quote:

---

Originally Posted by bensonsearch

Well done is all I can say. wish I had the ability to get my head around game programming, all I do is business apps (like to run a biz on).

---

Thank you ;)

To be honest, this type of thing isn't really all that difficult. Don't get me wrong, there are a lot of gotchas if you're doing something like this for the first time but after you figured it out, it's actually fairly easy. I had actually done this before so I pretty much already knew how to approach it.

Quote:

---

Originally Posted by bensonsearch

here is some chaos

Attachment 114139

---

You know you can resize the arena if you want to give them more room to fight. Use "+" to make it bigger and "-" to make it smaller.

Quote:

---

Originally Posted by bensonsearch

I should add that most times out of many, when matched evenly the blue afrit is a great unit, next to that if in numbers the iron lich hands down :)

---

Yea, I made the Afrits pretty powerful. As of now they have to most complex behavior of all the monsters. The BlueAfrit is my favorite unit. Spent a lot of time tweaking its definition. The Ironlich is something of a boss creature. It has the most powerful projectile and the most hitpoints.

Niya,

I had forgotten that I had a codebank contribution in the game programming codebank where I go game loops. It was a bit dated so I updated it today. I highly suggest that you check it out: http://www.vbforums.com/showthread.p...oop&highlight=

Quote:

---

Originally Posted by dday9

Niya,

I had forgotten that I had a codebank contribution in the game programming codebank where I go game loops. It was a bit dated so I updated it today. I highly suggest that you check it out: http://www.vbforums.com/showthread.p...oop&highlight=

---

Thanks. I will check it out.

What the :eek: ???? :confused:

Could you please stop spamming with this nonsense.

I keep getting it on my threads too. Is it all hieroglyphs with the occasional links?

Quote:

---

Originally Posted by dday9

I keep getting it on my threads too. Is it all hieroglyphs with the occasional links?

---

Yea. The Mods have since removed the posts and banned the user. Thank God.

Niya, I'm working on a game where players will have the option to capture the action and save it as mp4 video. Maybe even the ability to upload it to a players YouTube account. I think this would be a great option to add to your game. :)

Quote:

---

Originally Posted by Peter Porter

Niya, I'm working on a game where players will have the option to capture the action and save it as mp4 video. Maybe even the ability to upload it to a players YouTube account. I think this would be a great option to add to your game. :)

---

Not a bad idea. I'll look into it.

Updated to version 5.0.0.0. See OP.

Made a correction in the OP: Forgot to include the bug fix for the error reported in post 26 in the list of changes for version 5.0.0.0

Updated to version 6.0.0.0. See OP.

Hi Niya. Just downloaded the project and took a look. Nice work, and nice code, too. This is a very cool accomplishment for VB.Net!

I'm not particularly familiar with XNA, so I may not have anything useful to share, but off the top of my head, here are some easy ways to improve performance of generic GDI+ functions. (It's entirely possible you are already doing these things, so disregard as necessary!)

- Make sure all images are forced to premultiplied alpha (PARGB). It's not always obvious if GDI+ is loading assets in ARGB or PARGB format, but maybe test to see if ARGB is being used.

- Experiment with the target graphics container settings. Things like wrap mode, compositing quality, and pixel offset mode can impact performance in unpredictable ways, and if switching to high-speed options doesn't cause any graphical issues, this can be a "free" gain.

- When caching bitmaps, look at using GdipCreateCachedBitmap specifically. (Sorry, I'm not sure of the managed names for some of these functions.) GdipCreateCachedBitmap takes a Bitmap and Graphics input, and returns a new "CachedBitmap" optimized for that specific Graphics object. This allows you to use GdipDrawCachedBitmap for a nice performance gain.

- Another alternative to cached bitmaps is to dynamically switch to GDI's AlphaBlend for rendering. I'm not sure of the easiest way to accomplish this with your current rendering model, but basically, instead of using .DrawImage, you would use .GetHdc to return a DC to the graphics container. Then use GDI's AlphaBlend (which is hardware-accelerated) to perform the draw, and of course .ReleaseHdc when you are done. You lose the benefit of sub-pixel positioning (because AlphaBlend takes integer inputs) but GDI's AlphaBlend is several times faster than GDI+'s DrawImage. The problem with this approach in managed code is easily pointing a DC at the source System.Bitmap object... I'm not sure the easiest way to do that.

Those are some of the simpler ways to improve performance. It's possible XNA does some of this for you, but if not, maybe there's an easy performance bump in there...? (Apologies if you're already doing all this - I haven't looked too closely at the code yet!)

Quote:

---

Originally Posted by Tanner_H

Hi Niya. Just downloaded the project and took a look. Nice work, and nice code, too. This is a very cool accomplishment for VB.Net!

---

I also have an older one written in VB6. That one works but the code is one huge mess. Not VB6's fault though. I was learning as I wrote it so undoing the many mistakes I made during development meant I had to do a lot of nasty patch work.

Since I moved to .Net, I've always wanted to re-write it. To my surprise it was much easier. I wrote the basic engine(Version 1.0.0.0) in only a couple days. This is one of the projects where I saw massive productivity boosts from the new Visual Studio IDE and the .Net Framework. To be fair though, the fact that I had done this before also helped. I already knew what to do.

Quote:

---

Originally Posted by Tanner_H

I'm not particularly familiar with XNA, so I may not have anything useful to share, but off the top of my head, here are some easy ways to improve performance of generic GDI+ functions. (It's entirely possible you are already doing these things, so disregard as necessary!)

- Make sure all images are forced to premultiplied alpha (PARGB). It's not always obvious if GDI+ is loading assets in ARGB or PARGB format, but maybe test to see if ARGB is being used.

- Experiment with the target graphics container settings. Things like wrap mode, compositing quality, and pixel offset mode can impact performance in unpredictable ways, and if switching to high-speed options doesn't cause any graphical issues, this can be a "free" gain.

---

I actually did quite a bit of experimentation with GDI+. I even made a thread when I was working on the GDI+ renderer. I never wanted to use XNA because of the extra hassle to install it but GDI+, no matter how much I try to optimize can never give me the performance I need. Alpha blending in particular was taxing the GDI+ renderer.

Quote:

---

Originally Posted by Tanner_H

- When caching bitmaps, look at using GdipCreateCachedBitmap specifically. (Sorry, I'm not sure of the managed names for some of these functions.) GdipCreateCachedBitmap takes a Bitmap and Graphics input, and returns a new "CachedBitmap" optimized for that specific Graphics object. This allows you to use GdipDrawCachedBitmap for a nice performance gain.

---

I could have used this suggestion. How much of a performance gain would I get ?

Quote:

---

Originally Posted by Tanner_H

- Another alternative to cached bitmaps is to dynamically switch to GDI's AlphaBlend for rendering. I'm not sure of the easiest way to accomplish this with your current rendering model, but basically, instead of using .DrawImage, you would use .GetHdc to return a DC to the graphics container. Then use GDI's AlphaBlend (which is hardware-accelerated) to perform the draw, and of course .ReleaseHdc when you are done. You lose the benefit of sub-pixel positioning (because AlphaBlend takes integer inputs) but GDI's AlphaBlend is several times faster than GDI+'s DrawImage. The problem with this approach in managed code is easily pointing a DC at the source System.Bitmap object... I'm not sure the easiest way to do that.

---

I actually implemented a plain GDI renderer after I gave up on GDI+. It was abandoned of course but you can still see the remnants of the GDI renderer in the code. AlphaBlend was the main API being used. I had read that GDI's blitting was hardware accelerated on Windows 7. To my surprise though, the GDI renderer was only marginally faster than the GDI+ renderer. I wasn't satisfied so I reverted back to the GDI+ renderer since it was less cumbersome as GDI+ is the native API for WinForms. Then I started working on the XNA renderer which gave me a massive performance boost. It was exactly what I needed.

Quote:

---

Originally Posted by Tanner_H

Those are some of the simpler ways to improve performance. It's possible XNA does some of this for you, but if not, maybe there's an easy performance bump in there...? (Apologies if you're already doing all this - I haven't looked too closely at the code yet!)

---

XNA is built on top of DirectX so I really can't get a better renderer. I was thinking about Cairo as a replacement because of easier deployment(It's a single DLL is it not ?) but the fact that it's not hardware accelerated means I would probably have the same performance that I did with GDI and GDI+.

My current performance problems no longer have anything to do with the renderer. It has to do with other aspects of the engine. For instance the current version performs too many removals from lists. Removing an item from a list is very costly since there is a LOT of copying going on and the engine does this several times each tick! There's quite a bit of refactoring that needs to be done along these lines. Another performance killer is collision detection. I have a solution but it can't be implemented without some major refactoring of the code that deals with targeting.

I was trying to come up with ways to improve performance without making massive changes but it seems that is all I can do now. I can't shortcut this. My last attempt at a shortcut, which involved using an IList implemented as a linked list so I can get O(1) removal was a massive failure. It gave me the O(1) removal but caused a host of other problems. This is what inspired by comments about using C/C++ in the other thread.