Setting texture wrap mode for SpriteBatch

Shawn Hargreaves wrote:

It's unlikely we'll be able to support full custom effects for SpriteBatch, because we're planning on doing some optimisations that will use a custom vertex shader to speed up sprite drawing. This is one of those cases where flexibility and optimization aren't really compatible, and for this scenario it seems most important to make the simple case as fast as we possibly can.

IThere is a slightly worrying message in that statement. For the target market that MS originally seemed to be aiming at, they key elements seemed to be flexibility and accessibility. The more time I have spent with XNA, the less those two elements appear to have been considered. I obviously can't comment on the final release but at this moment in time, this is how it seems... to me anyway.

Chances are that in the average game, the majority of sprites are going to need to be something more than the basic "draw them to the screen" type sprites. Therefore, shouldn't you conclude that the priority must be to allow the sprite system to be as flexible as possible, thus allowing every user access to as many features as possible?

What that statement is basically saying is "we'll give you a fast way to fill the screen with basic sprites", I would ask, "who wants to play a game where the screen full of sprites they see are just basic sprites?". I can currently throw around 1500 - 2000 sprites on screen, rotating and scaling but generally looking pretty boring. I would happily settle for a quarter of that, if I could use the same SpriteBatch system but have the ability to make each sprite more than just the image it is created from.

At the moment, the system is designed for the programmer and MS have already correctly stated that the best programmers don't necessarily make the best game creators. So is the philosophy to have okay games that look great? Or to have great games that look okay? At the moment, the two seem to be mutually exclusive.

As an artist, designer and to a slightly lesser extent, a programmer, I want to make great games that look great. The less flexible and accessible you make the system, the less chance people like me have of doing that. Admittedly, I am fortunate in the fact that if I really want an effect, I can draw it but that's not an ideal solution really.

LeeC22 at 2007-10-8 >

Shawn Hargreaves wrote:

Ideally we'd like to make a system that is infinitely flexible and infinitely fast and also infinitely easy to use, but in the real world, sometimes we have to make tradeoffs between those different goals!

but isn't the danger that you are making the tradeoffs in the wrong areas? It's like trading in an F1 car for a dragster because the dragster goes faster, all well and good until you try and turn a corner. I think it's worth remembering the target platform that a large percentage of XNA users are hoping to run their code on. My system is well below that spec and it doesn't need to draw basic things any faster. Have you seen what 2000, decent sized sprites looks like on screen... you can't see much else other than those sprites.

Shawn Hargreaves wrote:

In XNA we've tried to make a layered design so you can dig as deep as you want or need to go. The SpriteBatch is very simple and easy to use, and we will make it run as fast as we possibly can, but if you need to go deeper, we are still exposing the full effects system, vertex buffers, etc, so you can access whatever more advanced features you need for your game.

Why do you need the SpriteBatch to go as "fast as possible", why not just "fast enough"? Optimisation can happen outside the code and inside the code. Part of analysing the requirements for the system should be analysing the potential tasks for the system. There's no point optimising a system to throw 3000 sprites around if nobody is ever going to throw around more than 500. Lets face it, who wants to see a game with that many sprites that haven't got any kind of effect applied to them?

The concept of a layered design is great, except if the highest layer you can get at, is well above the technical ability of part of the user base you are aiming XNA at. What if you need to go deeper to get at the great stuff but aren't technically minded enough to go that deep? Are you saying "if you haven't got the technical ability to learn the indepth aspects of DirectX coding, then we hope you enjoy making basic games that nobody wants to see" after already having said "we want to put games development into the hands of the non-programmer"?

At the moment XNA doesn't let you go as deep as you want to go, it makes you go as deep as it wants you to go. There's a subtle but highly influential difference in those two statements. One is a system like nothing else, the other is the same as something else with a different name. From what I have seen, it could easily have been called DirectXNA.

Over the last 20 years as a games developer, I have seen on numerous occasions, fantastic algorithms, highly complex functions and infinitely adaptable classes... all wrapped up in a below average game.

When you do all aspects of games design as I do, you have to consider the benefits and implications of digging into what seems to be an overly complex API. In the end, you either give up, because you know you will have to resort to basic graphics which won't portray the game in the manner you envision. Either that or you move to a more accessible platform, which doesn't have the power and you restrict your game that way.

Imagine how inaccessible 3DS MAX would be if its material system was script based rather than the UI it gives you now. The manual would probably say "you can apply the super quick default material, or you can use our fully exposed, multi-effect material system by writing complex scripts to implement the highly desirable materials".

I'm sorry if this long post is boring, I just though it might be good to see the perception of XNA from the side of games development that XNA was partially targetted to. I haven't seen many other posts from designers or artists using the system, I wonder why that is?

LeeC22 at 2007-10-8 >

Shawn Hargreaves wrote:

We're doing our best to make things both as easy and powerful as we can. This is a longterm commitment, and we're currently just taking our first steps along that road, but I personally still think it's a pretty good first step. Regarding sprite performance, I think you may be underestimating just how important that can be. An awful lot of the high budget games I've worked on in the past do an awful lot of their work simply through rendering plain old scaled, rotated, alpha blended textured sprites! Especially when you come to implement particle effects, fire, explosions, smoke, etc, this really is a situation where the more sprites you can render, the better things are going to look.

I have to agree, what XNA is and what it is aiming to be is a fantastic idea. I hope I am not giving the impression that I think XNA is no good because that's not the case. I see this as the answer to my design ambitions, that will let me create games that programmes like Flash would not. I can grind flash to a halt with 100 sprites, it's horrendous. I would just hope though, that down that long road, the XNA creators have taken on board the feedback and provide something to benefit the whole development community, from complete teams to the one-man developer.

What I am concerned about with the sprite performance, is that unlike the past, we now have pixel shaders to dynamically create things that people like me used to hand draw. I actually envision (or hope to see) the increased use of volumetric particle systems in 3D games, so instead of using flat smoke, we get smoke with body and depth. People will want to create the sprite content at run time, rather than deal with pre-drawn images. I mean, if we wanted a glowing sprite, we previously had to draw a glowing effect that matched the shape of the sprite... for every sprite that needed to glow. Or if we wanted to simulate depth of field, we had to draw blurred sprites. Isn't the idea of pixel shaders that you no longer need to do that?

You have to agree too, that high budget doesn't necessarily equal high quality.

As I posted in another thread and on Connect, a wrapper designed for the non-programmer would be the ideal situation, that way everyone can access the content at their own level. I get the impression though that it is going to need a non-programmer to build it. Simply because the nature of the industry is that the programmers aren't really that interested in non-programmers doing their job and a lot just simply, won't accept it. I was discussing the exact same thing with a programmer friend the other night and he agreed. They can be an overly defensive and aggressive bunch at times, you can even see it on here if you look in the right threads. Yet if a programmer asks an "I want to know how to create graphics question" the help will flood in and not in some cryptic fashion either.

Which leaves us with the dilemma that one of us is going to have to learn this system inside out so that the rest can benefit what that one person learns. All that while we are designing the games and creating the artwork for it too... so you can see why we would like it to be a little bit more accessible.

Anyway, sorry for hi-jacking the thread to the OP but it's hard to attract attention if you start a thread of this type. i.e. one that actually discusses the merits and potential of XNA in a non-programmer context.

LeeC22 at 2007-10-8 >