Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 11 Nov 2006
Offline Last Active May 23 2016 11:47 PM

Posts I've Made

In Topic: Operating System Questions in Assembly

13 May 2016 - 10:03 PM

Yeah if you're trying to run exe files you're just going to make a windows/dos clone.  Whats the point in that?

The only Windows clone being actively developed is ReactOS, and it's unstable as hell.
Windows is still the de facto standard OS for PC.

This is like telling hardware guys back in the '80s that developing an IBM clone was a waste of time.

As braindigitalis said, you need an awful lot of work to get to the point of displaying graphics. Even writing your own 2D framebuffer drawing code is a considerable challenge, but you also need to write your own graphics driver.

In Topic: Is it real?

06 May 2016 - 10:53 AM



I made all the enviroment models and character models, alongside sound. Does it still take years to code everything?

First, you have to learn programming.
#1 takes about 4 years.

And how do you learn? Through practicing? But to practice you firstly need to know the syntax. And to know the syntax you have to read a book usually of 1000 pages, where i will just assume, you need somewhere like 300 pages for gamedev, which are scattered through the book.


Tutorials on the web are a good place to start if you need to self-teach.

In Topic: Time - the most important factor.

05 May 2016 - 06:45 PM

I primarily work on 2D and intentionally retro-styled 3D games.

I develop on a PC I bought for $150 in 2013. I test for low-end performance on a mid-range PC from 2005. In a few years I'll probably retire the older PC and use my current machine for low-end performance testing. I've never paid for developer tools, either.
Spending a small fortune on development PCs and software is a waste of funds better spent on paying someone for work (once you get to that point)

Game development takes an incredibly long time to learn to do well. Individual games take a long time even for the experienced.

In Topic: Use which kind of generic string?

03 May 2016 - 12:11 AM

If you want cross-platform internationalization, use UTF-8. You can convert UTF-8 to Windows wide strings (and the reverse) using MultiByteToWideChar (WideCharToMultiByte) with CP_UTF8 for use with Win32 APIs.

If you're only developing for Windows, with no plan for porting, just use Windows wide strings (UTF-16).

If you're not internationalizing your project, all this talk is pretty pointless; just enforce your native character encoding for internal strings, try to use the ANSI versions of Win32 functions, and if there is no ANSI version just tack L in front of the necessary string literals (IE L"I really hate that windows doesn't make ANSI versions of some new functions."). :)

In Topic: Procedural Universe: The illusion of infinity

03 May 2016 - 12:01 AM

Most celestial bodies orbit their star(s)/galaxy/etc in a disk. This means that from a distance, a galaxy or star system would appear to be a 2-dimensional object. Even inside a galaxy or star system, they're so relatively 2 dimensional that a quadtree probably makes more sense than an octree. Since objects with fixed orbits on the disk should rarely collide, you only need to worry about objects that have been shifted from their orbit (IE an asteroid the player pulled with their ship) and objects with orbits that cross other orbits (IE comets), maybe this is a better case to optimize for as far as collision goes.

Also, you'll need to adaptively load/unload nodes as the player approaches/leaves them. The number of stars in a galaxy, and the number of objects in a star system, it would be impossible to keep them all in memory. You need to keep as few as possible in memory. Ideally you'd use a PRNG to generate them, and then they can be reliably stored as just the PRNG seed. Then to show the node at a great distance (size <= 1px), you just need a cached hue and absolute magnitude.

About Oort clouds, Kuiper Belts and Astroid Belts - I'd generate them with a PRNG each time the player approaches, separate from the rest of the system. Too big and too much stuff to keep loaded when the player's nowhere near them.

I know that in order to overcome the floating point precision i would have to somehow scale the surrounding cuboids (spaces) in order to keep the depth buffer happy, this should be pretty easy, at least in theory.

You actually have several "space systems". You don't need to account for all of them for every object. Ignoring the player for a second:
1) Satellites (moons, orbiting ships, etc) only need to worry about their location relative to their planet. This can probably be on a 100km scale. Justification: accuracy of IEEE single precision ("float") is 7 digits. Mean distance ISS to earth is 400km = 4.0; mean distance moon to earth is 370,300km = 3703.0; mean distance Callisto to Jupiter = 1,833,000km = 18330.0 [Jupiter has satellites 10x more distant than Callisto, but they're all less than 200km diameter and boring]. This leaves a couple accurate digits behind the decimal point too.
2) Planets and inner solar system interplanetary objects only need to worry about their location relative to their star(s). This can probably be on a .1AU scale. Justification: same as above. Mean distance Mercury to Sun is .39AU = 3.9. Mean distance from Neptune to sun is 30.1 AU = 301.0. Fits very well in single precision.
3) Oort cloud constrained objects only need to worry about their location relative to local objects. This is probably best accomplished using a bounded volume heirarchy, where the bottom-level bounded volume contains some maximum of N objects, and you only compare each of those N objects against objects in the same bounds.
4) Kuiper belt constrained objects only need to worry about local objects. They also need to keep track of their orbit, but this can be a single value (eg in Radians).
5) Oort cloud and kuiper belt objects that enter the inner solar system during their orbits need to worry about inner solar system objects *ONLY* when they're in the inner solar system. There's numerous ways to implement this behavior.
6) If you want high def views of the planets surface from low orbit/high altitude, objects on the planet might also need to keep track of their latitude and longitude, OR you'll need to rig up some clever way to project surface geometry on a sphere.
7) On the galactic scale, you can probably get away with a 10 parsec scale (milky way is 30,000parsecs across = 3000.0; the nearest star to the sun is Proxima Centary, 1.3parsec = 0.13).

Adding in the player, you ALSO need to translate every object visible to the player into "player space" for rendering, culling, etc. Player space while in a ship will probably have a scale of ~10m (the USS Enterprise NC-1701 from the original Star Trek was supposedly 289 meters long=28.9, the T-65B X-wing from the original Star Wars trilogy was 12.5 meters long = 1.25).

Of course I'm assuming here you're going for a hard sci-fi game. If you're looking for mass appeal, using realistic coordinates is counter productive: nobody wants lightyears of nothingness before they hit their next star. So instead, you can probably use double precision and a 10km scale for a solar system which only has a diameter slightly larger than Jupiter (140,000km = 14000.0). For interstellar coordinates, you could just use the same scale, and add an int64_t in front of it (maximum size of galaxy = 9.2*10^18 jupiters), and for intergalactic coordinates just use a single int32 representing n*maximum_galaxy_size = n*9.2*10^18 jupiters = already crazy huge.