Sebastian Aaltonen Profile picture
May 19 19 tweets 4 min read Read on X
Recently a book was released about Nokia's N-Gage handheld game console. Back then Nokia was one of the most valuable companies in EU. They spent lots of money to conquer the gaming market.

I was the lead programmer in their flagship game.

Thread...

hs.fi/taide/art-2000…
The book realistically covers how crazy the spending of the money was. Nokia spent massive amount of money into marketing. They wanted to look like a gaming company. Big stands at GDC and other places. Massive launch parties, lots of press invited, etc, etc.
Their first problem was the hardware itself. N-Gage was identical hardware to their camera phone, except the camera was gone. Display was still vertical and very small. There was no GPU and no floating point unit in the CPU either.
The only SDK we got was just two functions: One to get the start memory address for display memory for direct write. Symbian gfx APIs were dead slow. The second one was for reading multiple key presses so that we could read diagonal (up+down) on dpad. That's it.
So the hardware wasn't really suited for gaming. Competitors all had GPUs back then. Nintendo DS also lacked FPU. PSP didn't, and it had a great GPU too. And competitors had bigger screens in landscape orientation. Much better designed hardware for gaming.
The first N-Gage version had MMC memory card slot under the battery. You had to take off the back lid and take off the battery to change your game. They didn't even bother doing hardware modification to add hotswap memory card slot. It was just a default phone hardware.
Their lead game Pathway to Glory (our game) shipped with full network capabilities. Nokia bought SNAP online library from SEGA. SEGA just quit their own console business and was licensing their online tech to GameCube/PS2 game developers. Nokia bought it fully.
This was actually a very good move from Nokia. SEGA knew what they were doing and they got their "Xbox Live" library just in time. It worked great. It was fun to be the first ones to play online games on a handheld device. It was magical...
But it was way too early. GPRS latency was almost 1 second (in average case). Unlimited GRPS data plan was +50€/month extra on your phone bill in Finland. Only rich people could afford that. And the phone didn't even have an internet browser.
I wrote our client side network code. We were among the first one to ship rollback netcode. This kind of netcode has become popular in fighting games recently. This was required to hide the 1 second network latency. We also designed the game to hide the network latency very well.
I wish they could have spent some of that massive marketing and PR budget to design a proper gaming device with GPU and FPU and a bigger landscape screen. SEGA's network tech was nice and they had big market share. Could have been a different story.
As said in the book, Nokia's launch schedule for the device was overly optimistic. It was just a minor HW modification as said above, so they only gave game devs one year to develop big games on the platform. They wanted same quality as Nintendo's own games back then.
Their early hardware and firmware had bugs and we had to debug these bugs to them, which wasted a lot of time. This added stress on top of the super tight schedule. Back in the day they didn't support OTA update, so there was a lot of stress to get firmware ready for launch.
So we were crunching a lot. At one stage we worked over a month in a row without any weekends. We ended up shipping the game and got 90+ Metascore too. So it was fine. But I was so burned out that I didn't participate in the sequel. I started writing our Sony PSP tech instead.
That was my personal Nokia N-Gage story.

Nokia hired the best game producers and marketing talent from Microsoft and others and succeeded on that front. But they didn't spent enough (if any) effort on the gaming device hardware. Their HW devision didn't seem to be on board.
Just wanted to add some tidbits about the tech in the Pathway to Glory game. As I said above, we had deterministic rollback netcode. We had terrain rendering tech that was similar to Comanche and Outcast (voxel heightfield tracer)...
The pathfinding algorithm was basically a 2d version of the modern Recast algorithm. We rasterized surroundings with software triangle rasterizer for A*, Back then we did this again for different radius units, as distance fields were not very well known back then.
We had a very early version of dynamic virtual texturing too. It was projected from above to the voxel terrain. Our whole terrain was textured with decals, just like modern VT terrains. We rendered the decals to the sides of projected VT offscreen texture when the camera moved.
We basically reused my old terrain tech for the Xbox 360 Trials games. Trials Evolution (Metascore 90) was almost the first 100% virtual textured game to ship. ID-software Rage shipped one month earlier.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Sebastian Aaltonen

Sebastian Aaltonen Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @SebAaltonen

Feb 14
I wrote my first engine (called Storm3D) during my University studies. Licensed it to FrozenByte and some other Finnish game companies. They shipped a few games using it.

It was a classic object oriented C++ code base with diamond inheritance. That was cool back in the day :)
In year 2000 object oriented programmer was based on real world examples "hawk is a bird" and people tried to solve diamond pattern issues with birds that were not flying. Later people realized that real world abstractions are bad. You should inherit/compose "flying" instead.
OOP isn't horrible if you model functionalities instead of real world abstractions. People also realized that composition is better than inheritance for most use cases. But the stigma of bad traditional OOP still lives on. OOP is not horrible when done right.
Read 8 tweets
Dec 27, 2023
Have been thinking about possible GPU-driven rendering approaches for older mobile GPUs. Traditional vertex buffers, no bindless textures, and no multidraw. Thread...
If you put all your meshes in one big mesh cache (1 buffer), you can simply change the mesh by modifying indirect draw call start index and index count. With indirect instanced draw call, you can modify the number of instances of that type.
HypeHype is heavily kitbash based platform. People build games by spamming lots of small object instances. I did some analysis and seems that the amout of different meshes is usually <100 in most games (<100k instances), so we only need 100 indirect instanced draw calls.
Read 24 tweets
Dec 22, 2023
Intel dropped Larrabee for a reason. The workloads just didn't exist back then. Dedicated AI processors are still niche.

In 2009 games were designed for Xbox360 & PS3. No compute shaders. Simple pixel/vertex workloads with minimal control flow...

tomshardware.com/pc-components/…
The simple SIMD design of Nvidia and AMD GPUs was just better fit for both power and performance for running graphics workloads of that era. Larrabee used modified P54C cores. It had 4 wide hyperthreading and wider SIMD units, but it was still more like a CPU than GPU.
In Xbox360/PS3 time frame the fixed function rasterizer and Z-buffering (including HiZ) hardware was super important. AMD and Nvidia had spent over a decade improving their rasterizers. At that point the rasterizer and geometry pipe was still quite significant portion of the GPU.
Read 9 tweets
Oct 26, 2023
New cascaded shadows GPU time = 68%

More precise culling helps a lot.

It's still a single render pass. 2048x2048 texture atlas. Three 1024x1024 cascades in it (last 1024x1024 region saved for local lights).

Let's talk about the correct way to cull shadows... Image
The old shadow rendering fit one shadow map to the whole frustum. Then it culled all objects using the shadow frustum, which is a ortho box. Object in areas marked with red can't cast a shadow to the visible frustum geometry. ~3x shadow draw count. Big waste.
The new algorithm uses view frustum back planes (in shadow space) to reject objects that cast shadows beyond the frustum (can't hit it).

View frustum front planes are not used, as they would cull away objects outside view frustum, but casting shadows on the view geometry...
Read 6 tweets
Oct 12, 2023
Figured out a fast way to do prefix sum of a byte mask (for draw stream compaction).

Let's assume we have a byte mask. 8 bytes inside a 64 bit integer. Each byte has their first bit set if that slot has data. Their values are 1, 256, 65536, etc...

Thread...
If we want to propagate a bit to all higher bits, we first multiply that bit by 1+256+65536+16M+... This is a fixed constant. Then we add this number to the result. Now all higher bits in the 64 bit uint have their counters increased if the first bit was one...
The same multiply instruction works for any other bit in the field. Will propagate it to 8*N higher bits. And add will accumulate them.

Thus you can process all of them using a single multiply + single accumulate. And you get a prefix sum in all of the bytes.
Read 8 tweets
Sep 18, 2023
Discussing about importance of ambient lighting techniques with our team. This screenshot is a perfect example how bad big shadowed areas look if you don't handle this problem in a good way. Image
The sun light (point light) is not the only light source outdoors. The sky light (big area light) is super important too. You need at least some level of approximation of sky light visibility to make the outdoor rendering look good.
The big problem in above scene is that normal maps vanish completely. The directional term is not strong enough. This makes the surfaces look flat. All the fancy per pixel lighting vanishes, because the normal vector dependent term vanishes in shadowed areas.
Read 8 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(