Games Based Linux Distro

Started by
65 comments, last by mrbastard 20 years, 1 month ago
quote:Original post by RPTD
SDL uses MesaGL as far as i know which is a bit... a trouble child (at least for me it is, nearly ruined my system)... but i have not played ut2k4 yet... u2k3 was crap and bloatware so i don expect this one to be any better.


SDL does not use a particular OpenGL driver (e.g. Mesa). It just uses whatever OpenGL implementation is installed on the system already (e.g Nvidia, ATI, whatever). That is why it is useful. And no, it is not slow.

For those clamoring about the need for a standard, why reinvent the wheel? Why not contribute to and use the cross-platform library that we already have? I hate to keep spamming about it, but what is missing?

Just in case anyone is not familiar with it, here is a quote from the SDL site:

Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer. It is used by MPEG playback software, emulators, and many popular games, including the award winning Linux port of "Civilization: Call To Power."
Simple DirectMedia Layer supports Linux, Windows, BeOS, MacOS Classic, MacOS X, FreeBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. There is also code, but no official support, for Windows CE, AmigaOS, Dreamcast, Atari, NetBSD, AIX, OSF/Tru64, RISC OS, and SymbianOS.


There is also SDL_net for cross-platform networking. What else do we need? One of the hiderances to development on Linux is competing standards (e.g. KDE vs Gnome), so trying to create yet another 'standard' game dev library would not seem to help anyone.

Edit: Tang beat me to it...

[edited by - grazer on March 25, 2004 9:57:15 AM]
Advertisement
KDE vs Gnome?
huh?
X11 is the real minimal you need to drive a game and it will run on any linux having an X running.
and about SDL this can be right. I know that my system is running OpenGL at no problem cause I play on it and I test my project on it. SDL just wanted deadly MesaGL (it didn''t let me compile without it) and MesaGL completly messed up my OpenGL installation back then. in case of 2d all is ok with SDL just 3d it''s better to stick to plain OpenGL without turn-arounds in my opinion (and OGL is already crossplatform so why double-wrapping it?)

and the reason why companies don''t do this binary stuff is because they would have to compile every possible configuration with intel/amd and all those cpus with their special command sets. and under windows you don''t need it neither. compiling a game from source still yields the best results, no matter how well and experienced the company is made it.

Life's like a Hydra... cut off one problem just to have two more popping out.
Leader and Coder: Project Epsylon | Drag[en]gine Game Engine

quote:Original post by seanw
quote:Original post by RPTD
nope, wrong.

what they optimize is the code but what makes windows slow and linux fast is the fact that you compile your code for your machine not blended. windows games are coded blended (for intel/amd, minimal architecture command set that is common) and special asm stuff is hacking around. if you take the sources you compile for your very specific machine and the compiler will take all possible optimizations that apply.


What's wrong with providing several binary packages for different architectures? I'm sure if the speed increase was significant they would do something like this. Games companies aren't stupid, if they could save months of optimizing by changing some compiler flags and making more than one binary they will. I'm not saying individual optimizing won't make it faster, but is it really going to be more than 10% during actual gameplay? The CPU isn't always going to be the bottleneck anymore either and is often to do with memory bandwidth and the graphics card.

Besides, you're so unlikely to get the source code with the game that there isn't much point in discussing it. I guess this is a reason for architecture independent code (like Java bytecode) that can be optimized for the specific system it is running on, without having the source code. Seeing as the consumer market targetted for games only uses a handful of architectures though , along with the features of currently used languages, it would make more sense for the games company to compile the multiple binaries themselves.


Whoever said we are talking about open source games. I am talking about the OS here. If the OS is to be installed, it can be compiled during installation for the user's hardware config.

Speed increase should be more than just 10% of CPU time for a minimalist OS configured just to support enough features for games.

I believe the more threads you have, the more often the CPU has to flush the cache when processing the other threads which can add up to quite alot of CPU time. With Gentoo, you will likely have only 1 application process which is your game running. Just look at the system requirements of Halo Xbox and Halo PC. Both run on windows/DX. Yet the PC version is so much more laggy or even unplayable on a 733mhz.


[edited by - GamerSg on March 25, 2004 9:11:49 PM]
quote:Original post by GamerSg
Whoever said we are talking about open source games. I am talking about the OS here....


Ah, fair enough then.

1) if one process is working and all others are in a wait state (which they should be in a good system unless they have special full time jobs to do like a game) then those processes eat up exactly no cpu time, no flushing. that`s the trick about good multithreading.

2) the xbox has a modified win os and a heavily modified dx code. the reason why the pc version is slower is because the devers just made a lousy port by wrapping the special dx version of the xbox towards the pc version. i bet with you if they would `really` port it the game would run similar in pc.

Life's like a Hydra... cut off one problem just to have two more popping out.
Leader and Coder: Project Epsylon | Drag[en]gine Game Engine

quote:Original post by RPTD
1) if one process is working and all others are in a wait state (which they should be in a good system unless they have special full time jobs to do like a game) then those processes eat up exactly no cpu time, no flushing. that`s the trick about good multithreading.

2) the xbox has a modified win os and a heavily modified dx code. the reason why the pc version is slower is because the devers just made a lousy port by wrapping the special dx version of the xbox towards the pc version. i bet with you if they would `really` port it the game would run similar in pc.


1) Not really, they actually do take up CPU time because the OS should load them into cache and poll for any events. The checking might cost almost nothing, but the clearing of the cache to do this is costly.

2) Yes the Xbox has heavily modified windows to only have features required for gaming and gaming only. WinXP supports tons of other features and background processing which are not needed during gaming. This is why the Xbox performs better. As for modified DX, i doubt so.

Also i agree that most PC games are not optimised(mainly because PC''s are in general very powerful so developers get lazy) with a few exceptions(Quake 1-3/Halflife/Jedi Knight II/Starcraft/Diablo I that''s about all), but even then it would require lower requirements on a minimal feature OS.

I believe the best way would be to test an OpenGL game available on both OSes on the same machine.
true. with pc versions this works. i''ve got tripple boot (win, linux, beos) to test but if you want to test different hardware (intel/amd, nv/ati) then it gets a bit complicate and costs. even more complicate with consoles then.

and i''m sure the xbox uses a modified DX. reason? i know the opinion of the guys who work on the xbox emulator for pc and they stated that hijacking the roms is not so easy because besides the modified win2k (it''s a modded win2k) they''ve messed with the dx interface making it not so easy to emulate. i think they added special feature functions into dx to optimize for the specific hw in the xbox itself. it''s not heavy modified but enough to make simple porting not straight forward

Life's like a Hydra... cut off one problem just to have two more popping out.
Leader and Coder: Project Epsylon | Drag[en]gine Game Engine

This topic is closed to new replies.

Advertisement