Oh, shoot! I misunderstood what you meant - you're right, it is compiling source code into source code when you go from Gamema-- MMF, to XNA... I thought you meant how 'compiling' from XNA doesn't actually compile to native code, sorry :) But yeah, MMF is still (literally) compiling all your files into one cohesive relational thingy internally, even if its next step is then to split it back up into other files in a new format....
As for optimizing it, I think it's probably pretty fundamental things to how the engine works, unfortunately -- it's things like how there's a performance cost (that doesn't occur on normal PCs) every time you change what buffer you're rendering to, but I'm not sure whether that would even be an issue for a strictly 2D, back-to-front system. (There's no sort of 'cached' graphics in MMF, is there? Where you would generate an intermediary bitmap on the fly, and then treat that bitmap as though it were a normal graphic asset in your scene?)
Anyway, it might do to actually measure the frame rate internally, if there's any way to actually hook into the difference between a logical "frame" and an actual drawing to the screen... Maybe you're just responding to any input lag that your TV is causing? (It could be a noticeable amount, and it would probably be the first time you've felt that on one of your own games...)
Also, come to think of it, try making a 'release' build instead of a debug build. There is a ton of overhead in constantly leaving a little breadcrumb trail for itself through the program, and updating that state on your PC so it'll be ready in case of a crash, that it can not bother with if it's not a debug build; I'm not sure if that would make the difference, but it couldn't hurt to try!
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2012-09-06 01:15 pm (UTC)As for optimizing it, I think it's probably pretty fundamental things to how the engine works, unfortunately -- it's things like how there's a performance cost (that doesn't occur on normal PCs) every time you change what buffer you're rendering to, but I'm not sure whether that would even be an issue for a strictly 2D, back-to-front system. (There's no sort of 'cached' graphics in MMF, is there? Where you would generate an intermediary bitmap on the fly, and then treat that bitmap as though it were a normal graphic asset in your scene?)
Anyway, it might do to actually measure the frame rate internally, if there's any way to actually hook into the difference between a logical "frame" and an actual drawing to the screen... Maybe you're just responding to any input lag that your TV is causing? (It could be a noticeable amount, and it would probably be the first time you've felt that on one of your own games...)
Also, come to think of it, try making a 'release' build instead of a debug build. There is a ton of overhead in constantly leaving a little breadcrumb trail for itself through the program, and updating that state on your PC so it'll be ready in case of a crash, that it can not bother with if it's not a debug build; I'm not sure if that would make the difference, but it couldn't hurt to try!