Jump to content
Official BF Editor Forums

Feasible Soon To Write An Entire Fps In 100% Python


cobrachoppergirl
 Share

Recommended Posts

Most FPS and other games are written with C++ as the the core graphics engine, and use a higher level language such as Python or Lua for the scripting and gamelogic. So essentially a game is a grotesque fusion of two different languages, that have to talk back and forth to each other and create what I think is some kind of Frankenstein-ien beast. As we've found in modding practice, you can edit the game logic and have it recompiled by the system transparently at run time into a pseudo type of fast running Pcode, but if there bugs and garbage in the game engine C++ code that have been compiled and no source distributed with it, you are SOL at fixing those bugs or gaining access to features of the underlying system that were left unexposed to the other language (short of hacking at machine code with SoftIce if you are masochistically so inclined).

Given that dual cores are common place and necessary for a modern FPS,my question is, with the proliferation of quad and hexa core processors, will it be possible to dump C++ (which I consider to be brain dead rancid programming language right up there with Forth, Cobol, and Lisp) and write an entire lightning fast FPS purely in a super powerful, elegant high level language such as Python?

I myself can't stand Braces in C, they are like chart funk crap peppered all over the code (I mean, look at this nightmare, they can't even agree on what is the best way to handle all these infernal braces http://en.wikipedia.org/wiki/Indent_style ). If for nothing at all, and Python was the worst language in the world, which its not, I would use it over C any day just so I could indent with Tabs and the code know exactly what I meant simply by counting tab characters at the front of a line (Offside indenting - http://en.wikipedia.org/wiki/Off-side_rule ). Nothing could make more sense. I knew it when I first saw it, this was clean. No huge gross cludgy widget ladden IDE like VB.NET, no symbol chart funk everywhere, just a page of clean code submitted to an austere and minimalistic widget and junk free interpreter.

If someone could write an entire multithreaded game engine in Python, we could dump this locked up BF graphics engine (I forget the name, someone told me once), and port all our code over and start with something entirely open source.

So, how many years... or is this a crack dream? I've looked at game engine code written in C++, and I do not want to go down that ugly hole.

Edited by cobrachoppergirl
Link to comment
Share on other sites

While it would be nice to have a game engine written completely in python, it would still be very slow compared to one written in c/c++.

Given that dual cores are common place and necessary for a modern FPS,my question is, with the proliferation of quad and hexa core processors, will it be possible to dump C++...and write an entire lightning fast FPS purely in a super powerful, elegant high level language such as Python?

Yes, python supports multithreading, but it does not support multiple cores. No matter how many 'threads' you have running in python, they all are executed in the same interpreter, which is running on a single core. :/

Edited by amideadyet
Link to comment
Share on other sites

Another problem would be the total lack of graphics and sound capabilities in python. You would need to code a library for python to access those ( and it would probably be written in C or C++ :P ) Fast collision detection would also be a problem and would probably require a lot of callbacks .

Hint: A very fast collision detection routine is the RAPID library :

http://gamma.cs.unc.edu/OBB/

I successfully integrated it into a very simple but very fast FPS for the Nintendo DS. I'm afraid there's currently no way around C or C++ for writing an interactive game.

Link to comment
Share on other sites

And this brings us to the balance of convenience and performance. If you wanted a really fast engine, you'd program it in assembly (or, hell, learn the bytecodes and type it in a hexadecimal editor) - but that makes it very hard to read (and thus fix bugs and expand, also it's rigid as a... uhh... strong girder.)

At the other end we have a nice dynamic language like Python that can bend any which way you want, and you can read it and understand what it's doing at a glance - but it's interpreted, and therefore very slow. In between the interpreted and assembly are those mid-level languages which (try to) combine the speed of assembly with the flexibility of high level languages, and have moderate success with both. One thing I learned when doing the shaders is that you really have to be mindful of the lower level languages that whatever you're coding in is based on, because there are all sorts of ways it can make the assembly it produces more or less efficient, and it's often not logical.

For example, in HLSL/Cg, consider the following:

float a = 0.5;
float b = 1.0;
float c = 4.0;

float example = a + b * c;

and

float a = 0.5;
float b = 1.0;
float c = 4.0;

float example = b * c + a;

Which one is faster? The answer is the second one, because the first one requires two steps, and the second one requires one. Huh? Well, by putting the multiplication in front of the addition, it becomes a single "mad" instruction, which makes for much more efficient code. Also:

float a = 0.5;
float b = 1.0;
float c = 4.0;

float example = b * c - a;

and

float a = 0.5;
float b = 1.0;
float c = 4.0;

float example = b * c + -a;

Which one is faster? Again, the second one, because it's a "mad" again. If you add a negative number, it can do that, but if you subtract a number it becomes the separate subtraction and multiply.

Anyway, that was a massively unrelated thing, but if there's anything to take away from it, it's that as the level of the language gets higher, it gets harder and harder to make it efficient.

Link to comment
Share on other sites

Yep you can't make a game engine consisting purely of the "standard python" code. Python is text, a game is graphics, texture data, meshes and a lot of stuff around it.

If you want to make a python-based game; you'll need to:

- Write wrappers for the python code to execute in; the window, python loading and python-wrapper communication

- Make an input port for your "wrapper" so your python scripts can access it

- Make ALOT of base libraries for:

- mesh/texture loading and mesh-to-screen painting

- a sound engine

- a way of making the menu

- Develop a base hierarchical system so you can easily add children to parents. (as example, to add mesh parts to an object)

- Finally, make all possible "structures" in python you want to use. You can start with "object", "player", "mesh", "effect", "trigger" etc.

This all can take a while to do (approx. 3 years min?) This is why game makers often jump to existing game engines (frostbyte, source, Quake) because it has reasonable editor to fasten up the game making. If you REALLY want to make your own engine, you need to watch out for the following pitfalls:

- screen rendering is slow, you'll probably need to multi-thread your drawing operations

- the more "objects", the more you need to draw to the screen. 1 huge object takes less time to render than 100 small objects.

- you might need to develop your own geometry language (for the meshes). basically, you are storing 3 points for every surface and you give this surface a certain texture (and texture offset)

- The final performance limit is the performance of the computer.

- It will take long to build all the components. :P

At this point I am mostly discovering all 2D-related stuff of "engines", and based on that I know how the basic systems work. Also, I noticed refreshing the entire screen takes long and causes lag. My guess is that game engines store 2D object info (snapshot) and draw that to the screen. If you make every object render itself using a separate threading operation, you could make 3D objects more easily.

What a reply, hope it is useful. :D

EDIT

Forgot about DirectX :o

DirectX is sort of like a Windows Plugin that can handle 3D drawing, texture loading and more. It can be useful to use in game engines, and could make it easier to make a game engine. But DirectX is a wrapper, so you'll need to bridge it with your game.

EDIT

overview of existing (game) engines you can use to develop your own games:

WikiPedia engines

Edited by bergerkiller
Link to comment
Share on other sites

you'd program it in assembly
Agreed - i'd never do any serious stuff on slow uP's in any other language.

But one of the reasons for all those lazy game developers out there to use C or C++ is the libraries which wrap e.g. low level graphics stuff to the according 3D instruction set of the used processor , like the MMX stuff for Intel and SSE ( or whats it called ? ) for the AMD family. The game programmer doesn't need to take care about it, its the library which does the switching.

If you're sure the hardware never changes ( and thats one of the reasons for the game industry jumping to console games ) you could simplify the interfaces between game and hardware , accelerating the whole process.

Console games in fact could be much much faster if the game industry would program for them in Assembler but that narrows the choices for them to sell and port the stuff to other potentially profitable platforms.

Link to comment
Share on other sites

  • 2 weeks later...

I think if you want to write a real game with good graphics and networkcode you cant avoid coding the core in C++.

Some time ago i tried to rewrite a basic part of the python core (from C to C++) but i finally gave up because it were to many objects i had to change.

But one thing i recognized was that python is not written very efficient and often not very smart (for example the whole dictoffset thing).

I spent the last few weeks of my holidays (the last school holidays i'll ever have) to code a library which allowes you to easily integreate python into c++. Ill publish it here if you want (but im not yet finished).

Anyway: Python isn't meant to be a language you should write a entire game in.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...