Pong runs under Mono.Xna!
Stuart Carnie
implementation, unchanged! Game responds to keyboard, and I was able
to play successfully.
See this post with a screen shot: http://aussiebloke.blogspot.com/2007/04/running-pong-under-monoxna.html
There are issues with the textures, but I've no doubt we'll sort those
out quickly.
It does require SDL_Image.dll, libpng, zlib and SDL_gfx.dll
I'll submit an updated patch, which also resolved the GetHashcode
issue.
Cheers,
Stu
Stuart Carnie
It was calling Surface.Resize() in the Load(Surface) call.
this.width = surface.Width;
this.height = surface.Height;
surface.FlipVertical();
// Commented out this line
//surface.Resize();
This changed the image size to a power of 2. By removing this call,
all renders correctly. Is it no longer a requirement that the texture
be a power of 2? I have the latest SDL.NET 6 source, and this method
is commented out anyhow. Anyway looking for expertise here.
Cheers,
Stu
Alan McGovern
Ok, a few comments ;)
You've broken some existing NUnit tests, specifically when loading textures they are *not* always loaded into the graphics device.
GetHashCode() should not be used for equality testing as two items with the same hashcode may not be .Equal(). I already said that to ya after you posted this patch so I'm just hassling you to make sure it gets fixed ;)
Also, (i'm not sure if this is my problem or yours) but if i run the testsuite, i get null ref errors in the "Graphics" tests when on MS.NET so i can't run the testsuite to verify it passes on MS.XNA.
Finally, i had to make a few minor alterations to your code to make it compile. So to avoid me having to redo those alterations when you get around to fixing the problems in the Graphics tests (assuming they're not problems on my side), could you create a diff against the files used in the last patch and your new changes? That way i can just apply the diff on top of the old patch to make my life easier.
Other than that, things look very good. Admittedly i didn't have an extremely detailed look at the code, but i will when the tests pass ;)
Alan.
Stuart Carnie
Thanks for all the feedback Alan.
I think that answers an earlier question I posted - I can create a
patch and then a diff which is changes, relative to the patch?
With regards to GetHashCode(), I resubmitted the patch and thought I'd
fixed the Equals issues. If not, I'll sort it out.
The unit tests pose for the Game loop pose an interesting problem - I
compiled against the MS implementation and immediately it was the
issue that I'm unit testing with my internal clock (IGameClock) which
is conditionally compiled when NUNITTESTS is defined in M.X.F.G.dll,
and therefore does not exist for the MS implementation. As I
discussed in an earlier post, it exists so I can create a 'step based'
clock to test numerous behaviours of the FixedGame mode.
Couple of approaches:
1.
I could leave it in, and use a conditional to run some 'extended' mono
tests, and exclude these specific tests when running against the MS
implementation.
2.
Move back to a 'real-time' testing mode and remove the IGameClock
interface. I'll run the real-time tests iteratively, and exit after a
set period of time. Given 1-2 seconds run time, our game loop and the
MS should be the same. This way, I can run all my tests against the
MS ref and compare. I see this has benefits, since if anything
changes in the MS implementation, we'll be notified by these unit
tests breaking. Still there could be runtime issues, where tests fail
periodically if the machine gets tied up for too long and the timing
is out.
I consider option 2. the preferred even if it is more work for me to
redo the game tests :)
On a side note, I ran the pong example under mono (on win32), and it
worked just fine. I decided to run my port of the Frodo C64 emulator
under mono, and it too worked unmodified - I'm most impressed!
On Apr 20, 4:43 am, "Alan McGovern" <alan.mcgov...@gmail.com> wrote:
> Hi,
>
> Ok, a few comments ;)
>
> You've broken some existing NUnit tests, specifically when loading textures
> they are *not* always loaded into the graphics device.
>
> GetHashCode() should not be used for equality testing as two items with the
> same hashcode may not be .Equal(). I already said that to ya after you
> posted this patch so I'm just hassling you to make sure it gets fixed ;)
>
> Also, (i'm not sure if this is my problem or yours) but if i run the
> testsuite, i get null ref errors in the "Graphics" tests when on MS.NET so i
> can't run the testsuite to verify it passes on MS.XNA.
>
> Finally, i had to make a few minor alterations to your code to make it
> compile. So to avoid me having to redo those alterations when you get around
> to fixing the problems in the Graphics tests (assuming they're not problems
> on my side), could you create a diff against the files used in the last
> patch and your new changes? That way i can just apply the diff on top of the
> old patch to make my life easier.
>
> Other than that, things look very good. Admittedly i didn't have an
> extremely detailed look at the code, but i will when the tests pass ;)
>
> Alan.
Alan McGovern
I think that answers an earlier question I posted - I can create a
patch and then a diff which is changes, relative to the patch?
Yup, that should work fine. If you take your initial changes as your "base" version, just create a patch to give me the fixes as compared to that. That'd be perfect.
With regards to GetHashCode(), I resubmitted the patch and thought I'd
fixed the Equals issues. If not, I'll sort it out.
I saw another few places where you compared for equality using hashcodes, so thats why i mentioned it again ;) No worries though.
Couple of approaches:
1.
I could leave it in, and use a conditional to run some 'extended' mono
tests, and exclude these specific tests when running against the MS
implementation.
That'd be fine i think. I'd be happy if this at least worked. You could do a runtime check to see if you're running under MS.XNA or Mono.XNA and if it's MS.XNA, you can just not run the tests (i.e. at the start of the tests add a line like: if(InMSXNA) return;). To do this, just use reflection to check if the SteppedGameClock exists, if it doesn't, you're in MS.XNA.
2.
Move back to a 'real-time' testing mode and remove the IGameClock
interface. I'll run the real-time tests iteratively, and exit after a
set period of time. Given 1-2 seconds run time, our game loop and the
MS should be the same. This way, I can run all my tests against the
MS ref and compare. I see this has benefits, since if anything
changes in the MS implementation, we'll be notified by these unit
tests breaking. Still there could be runtime issues, where tests fail
periodically if the machine gets tied up for too long and the timing
is out.
This would be more useful in that we have a testsuite the runs exactly the same on MS.XNA and Mono.XNA. But i don't think it's critical that we rewrite all the tests now.
On a side note, I ran the pong example under mono (on win32), and it
worked just fine. I decided to run my port of the Frodo C64 emulator
under mono, and it too worked unmodified - I'm most impressed!
I'll give pong a shot later on and hopefully it'll run for me ;)
Thanks,
Alan.
Stuart Carnie
bytes? I'll use this as my base for creating additional DIFFs.
On Apr 20, 10:26 am, "Alan McGovern" <alan.mcgov...@gmail.com> wrote:
> > I think that answers an earlier question I posted - I can create a
> > patch and then a diff which is changes, relative to the patch?
>
> Yup, that should work fine. If you take your initial changes as your "base"
> version, just create a patch to give me the fixes as compared to that.
> That'd be perfect.
>
> With regards to GetHashCode(), I resubmitted the patch and thought I'd
>
> > fixed the Equals issues. If not, I'll sort it out.
>
> I saw another few places where you compared for equality using hashcodes, so
> thats why i mentioned it again ;) No worries though.
>
> Couple of approaches:
>
>
>
> > 1.
> > I could leave it in, and use a conditional to run some 'extended' mono
> > tests, and exclude these specific tests when running against the MS
> > implementation.
>
> That'd be fine i think. I'd be happy if this at least worked. You could do a
> runtime check to see if you're running under MS.XNA or Mono.XNA and if it's
> MS.XNA, you can just not run the tests (i.e. at the start of the tests add a
> line like: if(InMSXNA) return;). To do this, just use reflection to check if
> the SteppedGameClock exists, if it doesn't, you're in MS.XNA.
>
Sounds good. I'll still need the conditional, since the interface
needed to be in M.X.F.Game.dll, to avoid a circular dependency between
this and the test suite.
I'll make sure you can run the tests against mono and ms without
error.
> 2.
>
> > Move back to a 'real-time' testing mode and remove the IGameClock
> > interface. I'll run the real-time tests iteratively, and exit after a
> > set period of time. Given 1-2 seconds run time, our game loop and the
> > MS should be the same. This way, I can run all my tests against the
> > MS ref and compare. I see this has benefits, since if anything
> > changes in the MS implementation, we'll be notified by these unit
> > tests breaking. Still there could be runtime issues, where tests fail
> > periodically if the machine gets tied up for too long and the timing
> > is out.
>
> This would be more useful in that we have a testsuite the runs exactly the
> same on MS.XNA and Mono.XNA. But i don't think it's critical that we rewrite
> all the tests now.
>
Okay - I will TODO that for later.
Alan McGovern
Stuart Carnie
Cheers,
Stu
On Apr 20, 11:24 am, "Alan McGovern" <alan.mcgov...@gmail.com> wrote:
> http://monoxna.googlegroups.com/web/ms-xna-fw-game-and-unit-tests-2.p...
>
> That should be it.
>
> Alan.
>