Some terminology distinctions as "voxel graphics" can cover a huge range of things.

• The term was used for a completely different technique in games such as Commanche and Outcast. There it was kind of a modified heightmap, but being rendered in a way quite different from how modern games convert them into a grid mesh of polygons. This was before ubiquitous polygon-based hardware acceleration.
• The output of medical CT scanners is voxel data, usually displayed as 2d cross-sections through the subject, or converted to polygons for 3d viewing with more modern machines.
• The Atomontage engine is a high resolution true voxel based system.
• Minecraft's worlds are I think best described as being block based, rather than voxel based. If we're to take the meaning of the word seriously: as a pixel is the smallest unit of a 2d image, so a voxel is the smallest unit of 3d volume data. But an individual Minecraft "voxel" might be a section of fence, a ladder, or all kinds of other things that are not a 1x1x1 cube. If the contents of a voxel can be something that only partially fills the voxel, then it is no longer the smallest unit of a volumetric data set.

The innovation that Minecraft found with respect to graphics is that people are willing to accept what would have been considered ugly in the days before Minecraft. We've always had the technology to represent landscape as a 3d grid, just as we've had the 2d grid of tile-based games for decades (often extended into 3d with multiple z-levels). It had always been assumed that the stepped hills and other blocky artefacts that a coarse 3d grid would necessarily form would be too ugly and unrealistic to use in a 3d game.

The lesson should be: People don't actually care much about graphical fidelity if the game's interesting enough to them.

The lesson bandwagoners heard: People love stuff that looks like Minecraft. Let's make stuff that looks like Minecraft, but we'll put high resolution textures on it so it looks more real!

Worth mentioning the golden rule of performance optimisation: Make sure you actually need to do it.

Although rendering to a larger screen area will inevitably be more taxing on performance, it is quite possible that it'll not actually harm framerate on a reasonable computer. And if it does cause problems you almost certainly have ample room to improve the efficiency of how your game is drawing graphics through Flash.

General rule using the standard graphics stuff is to avoid making it redraw vector images or rotated bitmaps. Instead you want it to be drawing, or copyPixel'ing untransformed bitmaps. Done correctly you can make even a traditional looking vector art game run orders of magnitude faster by automatically generating spritesheets and so on.

If you want serious graphical power then use Stage3D. Fullscreen complex 3D or 2D scenes with fancy shader effects all over the place is no problem then. Check out the Starling library for a simplified way of getting the power of Stage3D for 2D graphics.

From the looks of it, most of the animations are effectively standard cycling through frames stuff. For instance the run animation isn't leg bones getting rotated, it's swapping between a handful of running-leg animation frames (which might well be handled internally as being placed on bones, but the bones are static).

From what I can see in that video, the only times the bone system is really used is for ragdoll when the characters die. Possibly also for when angling guns upwards, but that's restricted to 45 and 90 degree angles.

Hello, some feedback from the demo on Steam:

The options menu is pretty buggy.
Before starting the game, I turned on fullscreen mode and selected my resolution. Selecting Apply didn't seem to do anything (possibly a flicker of a hastily abandoned context?). Using the Save option did set the display mode correctly. While in the game the Apply button did work correctly. I later came back to the options menu and it displayed incorrect ratio and resolution information. Also iterating through every possible resolution/ratio is a bit of a pain, a dropdown menu would be much more pleasant to use.

Already mentioned earlier in the thread, but alt-tabbing when in fullscreen mode messes up the graphics. It can be resolved by turning fullscreen off and back on again in the options menu.

I managed to get myself stuck just before the end:


When first entering the area I used the exploding dart gun on an enemy to knock myself upwards and the platform correctly appeared under my feet. As the arrows show, I continued on and ended up falling in lava. I respawned back where the player is shown in the screenshot but the platform above is now blocking my way up. The immediate solution is to block up where I fell down, but seems a bug that will crop up again especially in more complex levels, so I would advise some kind of checkpoint system that stores level state as well as player state.

At that final section the player has to navigate at the far corner of the screen which is kind of fiddly with the distortion effect. I think it would be a good idea to design areas so the player very rarely needs to move to the edges of the display.

I think the platforms that pop out to catch you after rocket-jumping would benefit from some visual indication of where they will be. Currently the player has to rocket-jump around with the hopeful assumption that a platform will appear to catch them, which leads to a certain amount of "I guess I'll just rocket jump and see what happens" rather than working out what to do.

I liked the game itself, some nice ideas in the demo and I look forward to seeing what the rest of the game comes up with. Also it took me a while to notice it, but the little fluid simulation for smoke/fire from explosions is neat.

[Strata]

This is my simulation/building game, showing some of the water physics and the ability to "slice" the view so the player can see stuff that's otherwise hidden underground. If you make a flinging kind of gesture when dragging, you can get rid of that section of land on a longer term basis, and do building etc. on the exposed area.
There's also a horizontal slice, but that doesn't look at neat in a GIF.

My plan is to put up a devlog in the next day or two once I get vegetation working. Was hoping to have it done today, but ran into some problems with aquifers. It'll probably be called Strata.

Depth information for a chunk of landscape encoded into RGB channels.
Technically not a fail as this is working correctly, but it's not meant for a human to gaze upon.

Flash is a pretty good game platform? The tooling is great but flash has no performance I have a pretty modern pc and yet games in flash have lags... And in another Tab WegGL is doing some point cloud rendering.) and also not right mouse button! :p
But Tooling might be the reason why many people end up with flash?
And isn't Adobe dropping Flash and going all HTML5 too?

Flash is indeed a good game platform. Its great weakness is that there's a long and rich history of people making incredibly poorly engineered games for it, thanks mostly to that popular tooling.

Flash now has low level hardware acceleration in MacOS, Windows, and mobile using the Stage3D API. Create vertex buffer objects, create shaders, pass them to the hardware and receive excellent performance.
Speaking of mobile, the death of Flash on phones was greatly exaggerated. Embedded Flash content in websites is basically gone, but you can fairly easily package up a SWF as an AIR app and put it in stores and sell it.
Flash has support for workers so you can get some multithreading going.
Flash does, indeed, have support for the right and middle mouse buttons.
Flash can even do some crazy voodoo with embedding C++ code within the SWF, which apparently then executes really fast. I don't have experience with that though.

Adobe's approach to Flash is to reposition it as being a platform for cross-platform games and high performance video (whatever that means). The tools they developed for Flash-based sites will probably become HTML5 stuff. But they are very much still developing Flash, and they're taking it in game-friendly directions. For instance they recently released a quite excellent profiler.

In my opinion Abode's failing with regards Flash is communication. Everyone seems to think that Farmville and Binding of Isaac represent the technological pinnacle of what's possible with Flash.

Anyway! I'm a happy programmer because I fixed some really unpleasantly hard to find bugs with my water physics. Although still some unfinished work with how the water is displayed so it appears to have gaps when running down slopes.
Coincidentally this is running in Flash, in browser, at 60 FPS.

What's the technical principle?

It's built around a (I believe) new type of landscape representation I've been working on for much of the last year which would take a while to explain. But the water's the interesting part anyway:

The water is based primarily on local effects, quite like the cellular-automata stuff used in Dwarf Fortress. But my world isn't based on a cube grid (although it is constrained to a grid on the X-Z plane) so the neighbours available to a cell varies depending on surrounding landscape and water volume within a cell. It calculates water pressure in neighbouring cells at the point where they touch and uses that to determine what fluid flow should happen.

Most games use pressure difference between neighbouring water cells to determine how much volume is transferred each update (although often obscured behind language about making water depth in neighbouring cells converge towards equality). Instead I use pressure difference to determine the 2nd derivative of volume transfer, effectively an acceleration in fluid flow. Each update the acceleration for that instant is calculated, the acceleration is applied to velocity, which in turn actually moves water volume. Because velocity is kept between updates there is a pleasantly smoothly applied overfilling of cells which gives rise to the waves and general sloshing about feel of the water.

Worth noting also that this isn't based on a height map like for instance From Dust's water is. So there could be an aqueduct carrying water over that valley and it would simulate just fine with no interference. Unless the aqueduct overflowed, in which case it would of course correctly interact with the water below.

(I'll make a devlog some time fairly soon. Been working on this for so long with nothing worth showing, it makes a nice change.)

This is handled by "packages". You'll notice at the top of your actionscript files you'll already have a line that reads:

Code:

package
{

Let's say you make a class BouncyBox that you'll put in /src/physics/, so it would be part of a package named 'physics'. At the top of BouncyBox.as use:

Code:

package physics
{

If you have other classes in the 'physics' package (and placed in the same folder) they can just directly access the BounceBox class. But for the rest of your project you'll need to import the classes you want from the package. For instance at the top of Main.as you might have:

Code:

package
{
   import physics.BounceBox;

By default FlashDevelop will automatically add import statements like that if it spots you using a class for the first time. You may have noticed that if you type something like var myShape:Shape; it will offer to auto-complete the Shape class name, and will quietly add the import statement for you.

All the standard Flash classes like Shape, Bitmap and so on are stored in packages too. For instance flash.display.Shape, which also shows you can use nested folders. For instance if you had a class in /src/physics/collision/ then you'd declare its package using:

Code:

package physics.collision
{

and you'd get access to that class from elsewhere in your project with the import statement:

Code:

import physics.collision.WhateverYouCalledThatClass;

A section of Rock Paper Shotgun's review of A Game of Dwarves is probably relevant to this thread, where Jim Rossignol discusses how the game represents the world:

Complicating this 3Dness slightly is the fact that the game is grid-based, so you are mining through a block-based world. This creates an issue for the Z-axis: you have to hit keys to take you up and down through the layers. This is important because you are digging through that space, which is represented either as black nothingness, or as a series of question marks, indicated a mystery target for excavation.

While it didn’t take long to grasp this verticality system, I had a nagging feeling that the decision to make the game based in a series of layers – from the grassy surface to the depths below – might be one that made sense, but to the detriment of how the game actually played. Not matter how long I played, I never quite came to terms with having to move up and down across so many layers, or having to “dig” in black space, or have to track my activities across the multiple layers. Time and again I buzzed with annoyance, or clicked on the wrong segment of nothing. And I say this as someone who never really loses track of things in 3D space: I’ve never had spatial issues with even the most head-twisty of videogames. This isn’t one that is overly complicated, just clunky. There’s a reason other games of a similar ilk have restrained their diggings to a single layer: it’s just more immediate, and has a better feel to it. Often, it looks better, too. I suspect that this decision, which lies at the very heart of Dwarves, will be the one that dogs it the worst.

Dwarf Fortress of course uses a similar system of the world being a 3d grid of cubes, with more or less only one horizontal layer visible at a time. I think it works more comfortably there for two reasons: First that layer is displayed in a flat manner as just a grid of symbols - compare to Game of Dwarves' 3d models that extend up into nothingness. Secondly the grid nature of the world is reflected in the grid nature of its display, such that as you flip through layers of the world a particular position is in exactly the same place on the screen for each depth.

In future versions of flash player you'll be able to use right-click properly, but who knows what %age of players will have upgraded to that version by the time your game is out.

That future version was 11.2, which was released in March 2012.
According to StatOwl by July 2012 82.31% of machines (I assume they're not counting mobile devices) had at least version 11.2 installed.

what is the goal here besides just taking pictures of mars's surface?

Determine if Mars could have once supported life.
Learn about Martian hydrology, geology, and climate.

On a practical level, our understanding of these fields is probably vital to humanity's long term success. But all our knowledge is based on studying just our own planet. In a universe with (probably) billions of planets we are making use of a rather small sample size.

On a more broad outlook it's learning about life, the universe and everything. To me that's just about the highest cause humans can work towards. We are the way in which the universe is able to see itself, and all that.

I wonder how did you think off such complicated (?) formula?

I'm not HernanZh, but I use a graphing tool like https://www.desmos.com/calculator when I'm looking for a particular effect.
For example if you want something that initially moves rapidly and then slows, 1 / x is likely to be useful. If you want something that oscillates then sine x is going to be useful.
Using that it's easy to experiment and find that y = (sin(x)) / x gives a nice dampened oscillation. Add some constants to the equation and that calculator allows you to drag a slider and vary them to see what effect they have.

It worked for me, and yep I do have .net Framework 4.0 installed.