 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/13/2011 23:40, Warp wrote:
> Why would you even want to decompress a JPEG image with the GPU?
That's a good point. ALtho I know the set-top boxes I've worked with all
have MPEG decompression hardware and H.264 decompression hardware, as do
most of the phone stuff I'm familiar with (which is very little). That's one
of the arguments about Ogg in HTML5 video tags vs H.264.
> (The reason why they are faster at drawing is extreme parallelism and
> having hardware that is dedicated to drawing stuff.)
I'm pretty sure the individual blocks of jpeg are independent (unlike PNG
for example). You ought to be able to de-convolve an entire jpeg in parallel
at least, once you de-huffman it.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/13/2011 23:41, Slime wrote:
> > It's more like "Gee, every other game manages to have really
> > sophisticated graphics and stuff like geometry for window ledges instead
> > of just being painted on. I wonder what I'm doing that I can't get 1000
> > flat walls drawn."
>
> When you put it like that, I have to imagine it's something you're doing,
Yes, exactly. I was hoping i could just be naive and do a
Wii-quality-graphics game without learning all about how to do complex stuff.
> although I have no idea what it would be.
Apparently, the XBox is slow at restarting the graphics card. If I draw the
models as 600 individual models, I get about 20FPS.
Switching to instanced drawing (where you draw 100 copies of the same model
in one draw call by first passing 100 world matrixes to the graphics card
and then writing basically a shader with nested loops over world matrixes
and verticies), I get 130FPS.
So, basically, setting the texture and vertex buffers are really slow, even
tho they're all stored on the GPU without needing to transfer them from the
CPU other than updating pointers. I think I don't know how the GPU
interfaces to the CPU at the hardware level very well. If I were serious
about this, I'd dig up a book on GPU assembly language.
> Are you using Direct3D?
I'm using XNA, which is MS's .NET wrapping of Direct3D (at least on the xbox
- I don't think it uses D3D on the WinPhone).
Fun fact: XNA stands for "XNA is Not an Acronym."
> Trying to minimize primitives?
That was basically my complaint. It's a simple enough game I was hoping I
wouldn't have to do that. There's no sweeping vistas or city-size sandboxes
or even animated models or (at this point) even *moving* models. :-)
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/13/2011 23:40, Warp wrote:
> What do you expect of a device that is cheaper than many cellphones?
If I hadn't seen awesome and visually stunning games running on it, I'd be
less surprised. I'm not complaining about the xbox. I'm complaining that
even seemingly trivial scenes with no motion and Wii-quality graphics takes
knowing a whole lot about graphics to render at a reasonable rate.
I guess the subject line could be read in a way I hadn't intended, as a
criticism of the hardware itself rather than "I regret it's harder than I
expected." :-)
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/14/2011 2:23, Patrick Elliott wrote:
> Because they can't, just to use the obvious example of games, make something
> that runs fine,
I can't even figure out who "they" is or what "something" it is that doesn't
run fine.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New escreveu:
> On 4/13/2011 23:41, Slime wrote:
>> Are you using Direct3D?
>
> I'm using XNA, which is MS's .NET wrapping of Direct3D (at least on the
> xbox - I don't think it uses D3D on the WinPhone).
a-ha! Are you sure 360 devs aren't actually coding in assembly? ;)
> Fun fact: XNA stands for "XNA is Not an Acronym."
I thought it'd mean something like eXtreme Nondisclosure Agreement. ;)
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> On 4/13/2011 23:40, Warp wrote:
> > What do you expect of a device that is cheaper than many cellphones?
> If I hadn't seen awesome and visually stunning games running on it, I'd be
> less surprised. I'm not complaining about the xbox. I'm complaining that
> even seemingly trivial scenes with no motion and Wii-quality graphics takes
> knowing a whole lot about graphics to render at a reasonable rate.
I'm wondering if part of the cause isn't XNA and C#. In theory it shouldn't,
but who knows about these things. After all, all those beautiful ginormous
games are certainly not done with XNA.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/14/2011 9:58, nemesis wrote:
> Darren New escreveu:
>> On 4/13/2011 23:41, Slime wrote:
>>> Are you using Direct3D?
>>
>> I'm using XNA, which is MS's .NET wrapping of Direct3D (at least on the
>> xbox - I don't think it uses D3D on the WinPhone).
>
> a-ha! Are you sure 360 devs aren't actually coding in assembly? ;)
Commercial developers use C++. If you want to release a game without MS
having to approve it first, you use XNA which (a) is way easier and (b)
locks you into a set of libraries that keeps you from (for example) stealing
user data, DDOSing whitehouse.gov, erasing other peoples' saved games, or
sending their music over the internet to your server.
>> Fun fact: XNA stands for "XNA is Not an Acronym."
> I thought it'd mean something like eXtreme Nondisclosure Agreement. ;)
I thought it was funny they out GNU'ed GNU, acronym-wise.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/14/2011 10:06, Warp wrote:
> I'm wondering if part of the cause isn't XNA and C#. In theory it shouldn't,
> but who knows about these things. After all, all those beautiful ginormous
> games are certainly not done with XNA.
I think that while XNA slows some things down, the graphics probably isn't
one of them. You have to be a little careful with memory management, but
there's enough value types that you can usually go without any per-frame
heap allocations if you're a little careful. The JIT optimizations aren't
great; certainly nothing like as good as on the PC. I don't know how fast
the CPU is, but in doing something like loading and decompressing PNG files,
my 3GHz 64-bit desktop machine runs the same code about 5x to 10x as fast.
The threading is a little wonky, in that threads won't move between cores
for example - you start a thread on a specific core and that's where it runs
(or starves, if you're not careful). I suspect the .NET framework itself
winds up taking up a fair amount of valuable memory if you're going to do a
serious game where half a gig is limiting. It doesn't unload code once
you've loaded it, so if you have a DLL for just posting your high score,
once you invoke that, it's going to take up memory while you play the second
round or whatever. (The actual graphics resources like fonts and images and
sounds can go, tho.)
Note that on Windows, where you can use stuff that's *not* part of XNA, a
lot of these restrictions disappear, too. They're just on the xbox for
sandboxing, basically.
But the graphics library itself makes you allocate vertex buffers and index
buffers, load compiled shaders as byte arrays, etc. It manages all kinds of
formats for the rendering targets and such, uses the DirectX libraries to do
a lot of the stuff like parsing .X and .FX files and compressing textures
and such. So all the underlying stuff is translated pretty much to DX calls
as far as I can tell. You have to deal with the graphics hardware at the
graphics primitives level. While there's a lot of simplification going on in
the library APIs, I don't think there's a lot that's time-consuming that you
wind up doing in C# itself.
Now if you did something even more sophisticated, like real physics or
per-triangle collision detection on a significantly-sized world, you'd
probably start seeing more limitations than I have. But in theory the JIT
should be able to turn that into code not too far off from C++, I would
think. Certainly no worse than any other C# code doing heavy math like that.
But the library calls still have you allocating a vertex buffer with a
declaration of which offsets within each vertex bind to which register in
the shaders, then filling it in a separate write-only call, assigning the
textures, then invoking the shader. And (except on the WinPhone) you can
write your own shaders in a separate C-like language (HLSL) which may very
well be what folks use to write DirectX shaders in non-XNA langauges too.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
have you looked into trying to use a ready-made engine instead of
rolling your own without extensive knowledge and optimizations? Try
some demo version of Unreal or something, though I don't know if they're
compatible with XNA.
There must be a reason why game engines are highly sought and valuable
assets.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/14/2011 11:15, nemesis wrote:
> have you looked into trying to use a ready-made engine instead of rolling
> your own without extensive knowledge and optimizations? Try some demo
> version of Unreal or something, though I don't know if they're compatible
> with XNA.
They're not compatible with XNA, because XNA is *only* C# because it is
sandboxed. There are a variety of small game engines for XNA that I haven't
really looked into. (Partly because they actually cost money, and while the
amounts they cost are trivial (like $100 is not uncommon), it's more than
I'm actually likely to make on the game. ;-) (Partly because I'm doing this
more to learn than I am to write games per se.)
I've read the Unreal documentation. Looks very cool. Way beyond what's
useful for a one-player simple game.
I'm thinking of trying out some of the Bryce stuff if I do a game after this
and need some animations that are too messy to do in raw code. (So far,
opening doors and stuff I have managed to do with math.)
> There must be a reason why game engines are highly sought and valuable assets.
No doubt. One thing Unreal does that from a programming point of view seems
to be really helpful is that it turns the event loop inside out. So you can
do something like "when you bump the wall, play the rub-head animation. Then
get back to me when that finishes." That's a whole ton of bookkeeping that
you have to do manually if your base library is "update all your objects for
this frame" followed by "draw all your objects for this frame" 60x a second.
It also has logic for path finding and stuff like that, at least in the
version I read about a couple years ago.
And of course all the level building and art sorts of things.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
