Still no sound, audio controls (so you can play your own music), and netcode was taken out.
If someone else wants to put up a release thread with post pictures after they test to be sure that the .ccgame i uploaded works that would be greatly appreciated [both the testing and then the thread creation posting after the testing is done].
N.B. itsnotabigtruck: I took care of the thread creation part.
Last edited by itsnotabigtruck; 11-13-2008 at 04:44 PM.
Reason: see comment above
first and foremost, this is the best zune game out. Thank you very much!!!
Second......i updated my zune to 3.1 and.....NOW IT WONT RUN AT ALL!!! Is there a 3.1 compatible coming out soon?
Thanks for a release for 3.0 Pauliver. I tried it out and it seems really good so far, i'll edit with more feedback once i have played some more. Thanks Again
Yeah. Unfortunately it doesnt seem to run on 3.1 (the new firmware that doesnt allow freezing and has 3 more microsoft games, that i LOVE)
After you choose the players and level setting, it will just reset when you press start.
but still, I'm sure it's a good game, if you care to look into changing to 3.1, that would be uh?mazing
I really would like to update this to 3.1 however I haven't heard anthing "official" from MS about what the 3.1 update did (it fixed bugs?).
So while i can confirm this doesn't run on 3.1 [out of memory exception] I don't know why it I suddenly have less memory to run in [Again, I had to fix this before to upgrade to 3.0 so I'm sure it only use 16mb of ram].
If someone can provide more information, I would be happy to upgrade, but at this point I have no idea what my target ram usage would be so its hard to "upgrade" to it.
I really would like to update this to 3.1 however I haven't heard anthing "official" from MS about what the 3.1 update did (it fixed bugs?).
So while i can confirm this doesn't run on 3.1 [out of memory exception] I don't know why it I suddenly have less memory to run in [Again, I had to fix this before to upgrade to 3.0 so I'm sure it only use 16mb of ram].
If someone can provide more information, I would be happy to upgrade, but at this point I have no idea what my target ram usage would be so its hard to "upgrade" to it.
It added the 3 new official games (Sudoku, Checkers and Space Battle neé Zauri) and resolved a few, but not all, of the crash bugs people were experiencing. It shouldn't have made any major changes w/r/t XNA, especially since the XNA runtime hasn't changed versions.
No clue about the RAM stuff, or whether it's an intentional change or an unanticipated side effect.
It added the 3 new official games (Sudoku, Checkers and Space Battle neé Zauri) and resolved a few, but not all, of the crash bugs people were experiencing. It shouldn't have made any major changes w/r/t XNA, especially since the XNA runtime hasn't changed versions.
No clue about the RAM stuff, or whether it's an intentional change or an unanticipated side effect.
Yeah, i was under the impression that it was just a bug fix update. I had been told by the XNA team that they enforced the maximum of 16mb of ram in 3.0 [which is why NAME didn't run without an update since it was using more than 16mb of ram]. Since is not longer running in 3.1 but did run in 3.0 eithor the framework now uses more ram in 3.1 for some reason (giving the game less ram to run in), or the limit is no longer 16mb. Eithor way I'm currently thinking about potential solutions but there will be no quick fix for this since the limitations of the system aren ot fully known.
What i'll most likely do instead of dynamically drawing the terrain onto the background is make a bunch of "terrain pieces" and use those to "draw" the terrain. This should solve future memory issues as it will make the whole game run in less ram, however it requires a lot of experimentation as to what size and how many pieces i need to use in order to draw the terrain.
For example:
a 2x2 piece - need to draw 120*160 per frame, need to create like 6 [probably too expensive]
a 4x4 piece - need to draw 60 * 80 per frame, need to create 36ish...
[more reasonable, still a lot of draw calls, probably too many]
a 8x8 piece - need to draw 30 * 40 per frame, need to create ALOT..
[possibly too many to create]
I'll probably go w/ some sort of hybrid system where i have a variety of pieces and pick from them to build the screen so if half the screen is terrain it puts one big block over it.
any ideas/thoughts are welcome though [feel free to hit me up on AIM if you have a quick solution]
Yeah, i was under the impression that it was just a bug fix update. I had been told by the XNA team that they enforced the maximum of 16mb of ram in 3.0 [which is why NAME didn't run without an update since it was using more than 16mb of ram]. Since is not longer running in 3.1 but did run in 3.0 eithor the framework now uses more ram in 3.1 for some reason (giving the game less ram to run in), or the limit is no longer 16mb. Eithor way I'm currently thinking about potential solutions but there will be no quick fix for this since the limitations of the system aren ot fully known.
What i'll most likely do instead of dynamically drawing the terrain onto the background is make a bunch of "terrain pieces" and use those to "draw" the terrain. This should solve future memory issues as it will make the whole game run in less ram, however it requires a lot of experimentation as to what size and how many pieces i need to use in order to draw the terrain.
For example:
a 2x2 piece - need to draw 120*160 per frame, need to create like 6 [probably too expensive]
a 4x4 piece - need to draw 60 * 80 per frame, need to create 36ish...
[more reasonable, still a lot of draw calls, probably too many]
a 8x8 piece - need to draw 30 * 40 per frame, need to create ALOT..
[possibly too many to create]
I'll probably go w/ some sort of hybrid system where i have a variety of pieces and pick from them to build the screen so if half the screen is terrain it puts one big block over it.
any ideas/thoughts are welcome though [feel free to hit me up on AIM if you have a quick solution]
The main factor that you should be concerned about is the sum total of your texture sizes. Each texture is stored as an uncompressed 32bpp ARGB bitmap, meaning every pixel you load takes 4 bytes. When you render the textures, it's rendering onto a fixed-size backbuffer, so the number of draw calls shouldn't substantially affect memory consumption (though it might affect performance). The upshot of this is that a small number of compact textures rendered numerous times should yield the lowest possible memory consumption.
Well you said if your game worked, you wanted screenshots. unfortunately, the game restarts when you try to start a game. But, here are the "official" screenshots, just to keep us waiting for a 3.1 update:
Edit: I can't get the pics to show up!!!!!!!!!!!!!!!
__________________
"Because We're aliens, and that's how we roll." - Alec Baldwin
Last edited by theguywholoveszunehd; 11-26-2008 at 05:39 AM.
Reason: Pics didn't Show up!!!!!
This is slower (due to the 240 sprites of dimensions 1x700 drawn for the terrain). [As a result deformable Terrain is now a possibility, no tunnels though just lowering the terrain height]
It "feels" slower than before, some animations may need to be sped up.
Its time for feedback. What do you want?
What is your priority
1) Fix networking
2) Deformable terrain [no tunnels, just height lowering]
3) Fix animation speed [which animations need to be faster/slower]?
4) Track down that pesky bug that causes the camera to stop following the player sometimes
5) Something else
[RELEASE] Name 2.0 (with 3.0 support)
Which is here: 
