Jump to content
Sign in to follow this  
  • entries
    201
  • comments
    88
  • views
    100854

Porting

Sign in to follow this  
Metron

81 views

Gosh... getting the old source code from VS.Net 2002 edition to VS.Net 2005 is like porting your code from one platform to another.

I decided that whatever I do, I won't do the work twice and implement my code on any other OS than Windows. Therefore I decided to use those nifty secure crt function. You know? Those with an "_s" at the end! Like "sprintf_s" or "strcat_s". I don't have finished this yet. But I want to do this before I dig deeper into the multi thread stuff.

The main difference between the old functions and the secure ones is that you have to pass an additional parameter which is the target buffer size. Unfortunately, you will not get an "hey, you just wrote over buffer bounds". Well you get an heap error but then, you don't directly see the origin of the error but you'll remark, that a totally unrelated pointer will be set to an unusual (see undefined) value.

That happened to me when I used the "_s" functions for the first time. Well, now I'll have to keep track of any pointer math I do and adjust a "remaining buffer" value accordingly.

Since I have a multi core processor now, I tried out how my multi core capable memory manager behaves... unfortunately, I did not see that I had defined some macros that directly access the memory manager instead of passing through my "new" and "delete" functions. So I had to remove all macros, rewrite a "reallocate" function and check all source codes for direct memory manager accesses. That done, it works like a charm.

My plans for my engine (which will be reworked to be shader only), is that I will have several threads. At least one thread will manage the off disk loading so that I can queue some load requests and continue in my main game until the load request is satisfied (or until an error occurs). In that way I should be able to display any animated "loading" screen or so.

I think that I will keep my rendering stuff in my main thread because DirectX function calls must be in the same thread of the creator.

I still have to do some checks to see how the access to my interfaces (such as the stream loader or the system interface) behaves with multitasking but I think that I'll have to put some critical section in there, too (at least to the write functions and those where the internal memory is changed).

That's all for now...
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!