Versus Software   game + free time = duck

Every now and then I remember playing the games I used to play as a child. One of those games was Super Mario World for the SNES. The reason why I bring this up is because of this very cool trick you could pull off in the Forest of Illusion level. With it, a semi-skilled player could go from 0 to 99,999,990 points in a few minutes.

Here’s the video displaying you how to do it, it’s pretty neat:

Now as you watch it, you can see Mario jumping from Wiggler to wiggler, and while he does that he gets points and extra lives. Here’s the screen shots of his points:

And as continues to bounce, the lives he gets:

However on the 7^th wiggler jump he gets this symbol:

And then this one:

And so on and so on:

When I was 9 years old and saw those symbols for the first time, I had no idea what they were. The manual where I read this secret trick from said they were “secret super symbols that show how awesome you are!” But after reviewing this video a few times, I think I have a different opinion on what it might be: an offset pointer in video memory going haywire.

To understand what I mean by that, let’s have a quick discussion. In classic consoles programming, for an image (normally known as sprite) to be drawn into the screen, it’s done in the following sequence:

1. First you must load the sprite into memory. Sprites are usually stored in memory sequentially, so images are grouped together (for caching purposes). This also has the benefit of making animation algorithms easier to implement. Here’s how sprite memory for the NES Zelda looks like:
   
   This picture is taken from http://randomhoohaas.flyingomelette.com/RandomHooHaas-ripsprites.htm
2. You then use an offset pointer to inform the sprite rendering engine what part of memory to draw onto the video memory. This offset is usually in bytes. If you translate bytes to picture offsets, you are then able to ‘crop’ pictures and render individual sprites onto the screen. Assume I did that with the previous picture, and made an algorithm that given an (x,y) coordinate would give me the cropped out sprite. So for (4,3) I’d get the image below:
   
3. This cropped image is then copied into the video memory, which it in itself is then read by the output signal to a PAL/NTSC scan line renderer. The result is an image drawn onto the TV screen.

Given that condition, here’s one of the most basic animation algorithms for sprite based rendering. You’d load a sprite such as this:

Into memory and you’d use the sprite render pointer offset to interpolate between the frames. So you’d start with coordinates (0,0), then after  a few fractions of a second you’d switch to (1,0), then (2,0) and so on. Via this method you’d get an animation such as:

Given that technical description and the above Super Mario World glitch, here’s my assumption of what went wrong:

1. The game had a counter (let’s name it the jump_counter) that started at zero. This counter tracked how many times the player jumped on a “bouncy” object (such as the wiggler), without touching the ground.
2. As the player jumped on “bouncy“ objects, the game would use the jump_counter to track:
   1. The bonus the player would win: points and/or extra lives
   2. The associated image for such bonus.

So say the player jumped on a wiggler. The jump_counter would increase to 1 and render 1000 points. If the player jumped on another wiggler, the jump_counter would go to 2, and render 2000. As the player continued to “bounce” around, this process would continue.

So my assumption is that the algorithm was basically:

if( player_jumped_on_bouncy_object() )
{
    Jump_counter++ ;
    Points_variable += power_of_two( jump_counter ) * 1000;
    player_lives += ( jump_counter > 4 ) ? jump_counter : 0 ;
    ImageHandle Image_to_render = memory_offset_via_jump_counter(jump_counter);
   Render_image( get_player_bounced_pos(), image_to_render ) ;
}

Now let’s explain the above pseudo-code:

1. Perform this algorithm only if the player bounced on something.
2. We increase the jump_counter, which is the base counter for the entire algorithm.
3. We increase the number of points, based on 2 ^( jump counter ) * 1000.
4. If the player “bounced” on more than 4 objects in a row, he’d get an extra life per bounce after that.
5. We retrieve an imageHandle that is relative to the jump_counter variable. So if jump_counter is 1, the ImageHandle returned the 1000 point image. If it’s 2, the 2000, and so on.
6. We then render the image we just retrieved at the location where Mario bounced.

Simple, isn’t it? However there’s a bug in the above pseudo-code. We can only retrieve valid image handles when the jump_counter’s range is from [1,7]. What if we make a request when jump counters is equal to 8 and above?

And that’s the catch! We get an invalid pointer offset to somewhere else in memory! Since that memory area is used for what’s to be displayed on the screen, we get bits and pieces from other sprites.

Obviously this is all an assumption of what went wrong. I could be incredibly incorrect in my analysis, but at least it’s worth a shot. What are your thoughts on this one?

Today I finished reading this book: Writing Secure Code vol 2.

I picked it up when I went to the mall with my sister and a friend of hers. While they were chit chatting I was browsing the book store and started reading it. The first 50 pages felt rock solid with materials on how buffer overflows, off-by-one rounding errors and heap overflows could give users overwhelming potential risk over your system. So I bought it expecting to learn more on how to write good, solid and safe code.

After reading it I can definatly say that I did learn that, both the authors have extensive knoledge on this topic. What I really did enjoy though is that as the authors went further with the topics at hand they started giving personal experiences they had with software security and vulnerabilities.

They talked about the Microsoft Push Security Move, what they learned, common mistakes other developers told them, bets they made to see if anyone could crack their systems, etc. It’s filled with amazing little side stories on how certain issues rise from common misconceptions and how the authors dealt with them.

One of my favorites was when one of the authors found a critical security flaw on the software he and his team were developing. He discussed this issue with his  managers, but they saw no threat in it and told him to ignore it. So he used that exact bug to invade the general manager’s computer, proving his point on how deadly this bug was. The issue was then promptly resolved.

I think one of the implicit ideas both developers taught in this book is that for a manager to know how to deal with the management of developing safe software, he needs to understand how safe software is developed. In other words, and extending the idea to a broader term:

Good software managers are good software developers.

And I couldn’t agree more.

We’ll it took a while, but I managed to finally finish reading Michael Abrash’s Graphics Programming Black Book:

In some ways I feel ashamed to say that I ‘read’ it because it’s a behemoth of knowledge spanning over 1200 pages. Of course I learned a lot from it but it’s the sort of book I’ll read again and again and again until I can finally grok it. It’s a collection of over 10 years of Abrash’s papers and I doubt one can absorve it in a matter of months.

You see to learn programming concepts in a self taught manner I think it’s crucial to not only read the code in the book, but also write it down, play around with it, to truly understand what is being taught in its finer details. With my current project I intend to do just that, since it’s a FPS and the last chapters on the book concern directly with Quakes development at id Software, where Abrash worked.

What’s more interesting is that the author doesn’t focus only in the development aspect of programming, but in the general mentality of it. Not as one solves a problem, but the mind that solves it. As you become better in development I think you ask yourself less “how to solve this problem” but more of “what is the best way to solve this problem”. Abrash shows us several ways to solve a problem in the book, be it linked lists, spatial visibility or making a faster game of life, each one consistently faster than the other with either assembly optmizations, algorithm optmizations or rethinking the whole approach to the problem. The idea is to not expect that there is only one way to handle an issue. In his own words : “Assume nothing”.

The book is also quite pleasant to read, since the author narrates the development cycle more as a journal than a tech book. It’s quite interesting to read the last chapters where he focus on making a faster rendering back-to-front polygon rendering approach to Quake. Almost goes like this:

March 14, 1941. We begin our approach to the BSP tree, were still having heavy losses on how to figure out a way to make the spatial visibility problem faster. The worlds we want with Quake  feature at least 5000 polygons and in the worse case scenario we redraw each pixel 5 times. It’s too slow, we must take a better approach.

May 22, 1941. We sucessfully managed to create a potentially visible set (pvs) that managed to break into enemy lines. We will now proceed to use it to flank their defeneses.

June 10, 1941. We have now conquered the enemy’s battlefield. I’ve reduced the inner loop of the rasterizer to 2.5 cycles per texel. We decided to use z-buffering for drawing the enemy meshes, since it’s faster and not that big of a problem as we expected. Victory is eminent.

And so on. Overall the book can be divided into 3 parts:

• General assembly optimization techniques
• 3D rendering done via software
• Common 3D engine development problems and solutions.

I recommend it to anyone that’s interested in taking game development or programming in a seriously yet elegant manner. I learned a lot from it, and still intend to learn more.

Well, heres the second release of the editor and details on how it’s going.

Download here: vtool (101)

Didn’t manage to get as much work done in the editor as I wanted to (kind of a busy week), but I did manage to put in some details that I wanted. The opengl windows now resize themselves as the master window gets resized and I added an automatic resize button. It only works though when the number of windows is a perfect square: 1,4,9,16… Still trying to figure out how to handle the non square situations. I think i’ll do a drop down menu with several choices you can choose.

The top menu now is a rebar also. That means the user can position them as he wishes. I prefer that sort of design more than toolbars because users generally have their own work preferences.

My long term goal with this project is to have a very flexible editor where the user can edit in any way he feels comfortable with, and to achieve that it needs to be as customisable as possible. Ideally I see the user being able to have an environment with windows where he interacts with the “game world” in many ways. For example he can have one master window that sees the world on top where he can edit it, and two sub-windows where he can see on-sight how those changes are ocurring. If this system is robust enough he can change that to any way he wants.

I’m heading towards that sort of design because I think one of my flaws in designing both the Solis and World Train Royale editors is that they gave no artistic freedom for the user. I see artists messing around with Photoshop and they all have their preferences and designs they call their own, not Photoshop’s in itself.

By the way I still don’t know how to properly name this project. Anyone got any suggestions? Also I would like to get people’s feedback on the project. So if you were to use an FPS editor, what sort of features would you want to have in it?

Anyway I guess that’s it for now. My next goal is making the editor more interesting, so I’ll be adding level building next. Until then!

Ever since I read this book a long time ago, I’ve always enjoyed art history and it’s analysis. I like how art, specially painting and drawing is a form of craftsmanship, how one evolves with it in time. I do enjoy looking at great contemporary artist like

Anry Nemo

Daniel Lieske

As well as old wizards like Dali

and Caravaggio

One thing I find particular interesting is how clearly explicit is a GOOD artist from a good one. Sure we can go down the path of Picasso being top notch and a genius while not being the best painter in the world, but my focus right now is in skill.

You can see, an artist is good when he masters several techniques like body proportions, shading, lighting,  diffusion, blur, meaning, semantics, and so on. To me all the artist above mastered this and it’s clearly visible even to laymen their genius.

That’s a thing a I refer to as the difference between masons and sculptors. Both work with the same raw materials, sometimes even the same tools, but their product is what separates the Pieta from simply another wall.

A sculptor understands the material he works to a point of such mastery that there is no limitation to what he can construct, all he needs is just time and resources. A mason while he may be good at it and could even attempt such a feat, in the end he would never reach such level.

There is clearly a distinction between the two, but what causes it? This change, that makes a beginner that is once a mason become a sculptor? What is the road to mastery?

I ask myself this question because I often draw parallels in between art and software development. Because I could just as well ask the same questions:

What defines a master developer? How does one become a genius in software construction? What is the road to mastery?

It’s easy to discern a great artist from an average one, all we have to do is look at their work, but how could we do this with developers? I usually read this in forums or talk with colleges and it usually revolves around with –

A great developer:

• Knows many languages
• Knows difficult languages
• Develops a lot
• Develops for fun
• Knows a lot about development
• Read a bunch of books
• Wrote a bunch of articles or even books
• Develops big products
• Never/rarely has bugs

And so on and so forth. Personally I think these criteria are fine but in the end, with them, you can’t discern a good mason from a sculptor. Knowing many languages doesn’t mean mastery of software construction, developing big products can be bottled down to trivial tasks such as mundane functions, lack of bugs can be either due to an easy to work environment or lack of new challenges.

My point is you can counter each one of those statements, thus failing to reach anywhere when trying to label an individual as a mason or a sculptor. What I believe is the way to go is something more along the lines of:

• A mason, given time, is able to solve most if not all known problems.
• An individual that is in between the two finds problems that haven’t been asked before.
• A sculptor is able to answer them.

I say this mainly because of my reference of what I consider to be great sculptors and their history, guys like Carmack, Abrash, Sweeney, Bram Cohen and so on. These guys managed to find problems no one faced before, or if they did no one answered, and then managed to find a solution of their own.

They did this because they knew their developing languages, their work environment, the machine down to the bitwise, to the electrical signal, to its deepest mathematical roots.

That to me is mastery. These are great artists. These are software sculptors.