Anti-Jammer-Thread
- Chromanoid
- Moderator
- Beiträge: 4263
- Registriert: 16.10.2002, 19:39
- Echter Name: Christian Kulenkampff
- Wohnort: Lüneburg
Re: Anti-Jammer-Thread
@Schrompf: Falls Du es noch nicht kennst, da stehen glaube ich viele nützliche Tipps: https://developers.google.com/international/i18n via diesen interessanten Goolge IO Talk https://developers.google.com/events/io ... /383370298
- Schrompf
- Moderator
- Beiträge: 4884
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas Ziegenhagen
- Wohnort: Dresden
- Kontaktdaten:
Re: Anti-Jammer-Thread
Uff... immer wenn ich gerade grob ein Thema bewältigt habe, lädst Du nochmal zwei Tonnen Wissenswertes auf mir ab.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
- CodingCat
- Establishment
- Beiträge: 1857
- Registriert: 02.03.2009, 21:25
- Wohnort: Student @ KIT
- Kontaktdaten:
Re: Anti-Jammer-Thread
CUDA 5.5 ist da - und funktioniert. Damit kann ich jetzt tatsächlich auf VC++ 2012 umsteigen.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
- Krishty
- Establishment
- Beiträge: 8268
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Ich habe Alpha to Coverage via Direct3D 10.1s Coverage Output implementiert, und meine Sprites sehen auf einen Schlag deutlich besser aus:
Interessenten finden Quelltext auf Seite 51 der DICE-Publikation DirectX 11 Rendering in Battlefield 3.
- Schrompf
- Moderator
- Beiträge: 4884
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas Ziegenhagen
- Wohnort: Dresden
- Kontaktdaten:
Re: Anti-Jammer-Thread
Hab mir die Präsentation angeschaut, aber ich verstehe nicht genau, worauf Du Dich dazu beziehst. Schreibst Du jetzt gezielt im Shader die Coverage-Samples, und das Resolve der GPU ergibt nachher die sauberen Sprite-Kanten?
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
- Krishty
- Establishment
- Beiträge: 8268
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Ja; genau. Weil seit Direct3D 10 bei Multisampling der Versatz jedes Samples fest definiert ist, kann man im Shader ausrechnen, an welchen Stellen die Textur bei MSAA abgetastet würde. Dann samplet man diese Stellen selber, und falls der Alpha-Test das Sample behalten würde, setzt man das entsprechende Bit in der Coverage Mask. In der Ausgabe bedeutet das dann Sprite-Kanten, die genau so glatt sind wie die tatsächlicher Dreiecke.
Nervig ist, dass man bei unterschiedlichen AA-Stufen entweder je einen passenden Shader schreiben muss, oder Leistung wegschmeißt. Weil ich aber erstmal bei 4×AA bleibe, kann ich es mir leisten.
Nervig ist, dass man bei unterschiedlichen AA-Stufen entweder je einen passenden Shader schreiben muss, oder Leistung wegschmeißt. Weil ich aber erstmal bei 4×AA bleibe, kann ich es mir leisten.
Re: Anti-Jammer-Thread
Gut zu wissen :)CodingCat hat geschrieben:CUDA 5.5 ist da - und funktioniert. Damit kann ich jetzt tatsächlich auf VC++ 2012 umsteigen.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
https://jonathank.de/games/
- CodingCat
- Establishment
- Beiträge: 1857
- Registriert: 02.03.2009, 21:25
- Wohnort: Student @ KIT
- Kontaktdaten:
Re: Anti-Jammer-Thread
Ich habe soeben einen Weg gefunden, das alte new zur Compile-Zeit zu unterbinden:
Überladen von new:
Mit:
Auch in anderen Compilern: http://ideone.com/agWsO3
Nachtrag: Es kommt noch besser, die MSVC 2013 STL kann mit new-Makros umgehen. Die nutzen tatsächlich Makrogeltungsbereiche in Form von #pragma push_macro("new") #undef new #pragma pop_macro("new"), womit eigene new-Makros direkt unterstützt werden.
Code: Alles auswählen
int main()
{
auto test1 = new_unsafe int; // test1 hat Typ int*
auto test2 = new_unique int; // test2 hat Typ unique_ptr<int>
return 0;
}
int main_doinitwrong()
{
auto test = new int; // error C2065: 'new_is_deprecated_resort_to_new_unique_new_shared_or_new_unsafe' : undeclared identifier
return 0;
}
Code: Alles auswählen
struct test_custom_alloc
{
void* operator new_unsafe(size_t size) // oder: void* operator_new(size_t size)
{
return ::operator new_unsafe(size);
}
};
Code: Alles auswählen
#include <memory>
#define new new_is_deprecated_resort_to_new_unique_new_shared_or_new_unsafe new
#define resolve_new_is_deprecated_resort_to_new_unique_new_shared_or_new_unsafe
#define resolve_xx(x) resolve_##x
#define resolve_x(x) resolve_xx(x)
#define operator_new operator resolve_x(new)
#define new_unsafe resolve_x(new)
struct new_unique_tag { };
template <typename T> std::unique_ptr<T> operator *(new_unique_tag, T* p) { return std::unique_ptr<T>(p); }
struct new_unique_array_tag { };
template <typename T> std::unique_ptr<T []> operator *(new_unique_array_tag, T* p) { return std::unique_ptr<T []>(p); }
#define new_unique new_unique_tag() * new_unsafe
#define new_unique_array new_unique_array_tag() * new_unsafe
Nachtrag: Es kommt noch besser, die MSVC 2013 STL kann mit new-Makros umgehen. Die nutzen tatsächlich Makrogeltungsbereiche in Form von #pragma push_macro("new") #undef new #pragma pop_macro("new"), womit eigene new-Makros direkt unterstützt werden.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Re: Anti-Jammer-Thread
Sind die Bilder unterschiedlich? :?Krishty hat geschrieben:Ich habe Alpha to Coverage via Direct3D 10.1s Coverage Output implementiert, und meine Sprites sehen auf einen Schlag deutlich besser aus: Interessenten finden Quelltext auf Seite 51 der DICE-Publikation DirectX 11 Rendering in Battlefield 3.
Ohne Input kein Output.
- Artificial Mind
- Establishment
- Beiträge: 802
- Registriert: 17.12.2007, 17:51
- Wohnort: Aachen
Re: Anti-Jammer-Thread
Im neuen Tab öffnen hilft häufig ;) Achte mal insbesondere auf die "Gitterstreben", da ist der Unterschied mMn am deutlichsten.BeRsErKeR hat geschrieben:Sind die Bilder unterschiedlich? :?Krishty hat geschrieben:Ich habe Alpha to Coverage via Direct3D 10.1s Coverage Output implementiert, und meine Sprites sehen auf einen Schlag deutlich besser aus: Interessenten finden Quelltext auf Seite 51 der DICE-Publikation DirectX 11 Rendering in Battlefield 3.
Re: Anti-Jammer-Thread
Naja ok man sieht kleine Unterschiede, aber für deutliche Unterschiede sind meine Augen dann wohl zu schlecht.
Ohne Input kein Output.
-
- Establishment
- Beiträge: 467
- Registriert: 18.04.2002, 15:31
Re: Anti-Jammer-Thread
In der Vorschau sieht man tatsächlich keinen Unterschied, aber in groß ist das obere doch extrem pixelig and den Gitterstreben und wenn selbst ich die sehe, dann heißt das schon was.
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da :)
"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
DirectGL, endlich ist es da :)
"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
- Krishty
- Establishment
- Beiträge: 8268
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Das Hello World / fuck C++ in LLVM Assembly funktioniert.
Verblüffend einfach sogar! Ich hatte am Anfang arge Probleme, weil sie für Windows nur MinGW-Binaries anbieten, die auch tatsächlich eine MinGW-Installation voraussetzen. Sobald das installiert ist, fluttscht es aber wie nichts:
Keine Forward Declarations wie in C. Ich rufe was auf und deklariere oder definiere es hundert Zeilen später. Falls es aus WinAPI oder CRT kommt, findet der Compiler es ohne weiteres Zutun in den MinGW-Bibliotheken.
EIN TRAUM
Der weitere Plan ist:
Verblüffend einfach sogar! Ich hatte am Anfang arge Probleme, weil sie für Windows nur MinGW-Binaries anbieten, die auch tatsächlich eine MinGW-Installation voraussetzen. Sobald das installiert ist, fluttscht es aber wie nichts:
- Quelltext in eine Textdatei
- llvm-as test.ll für menschenlesbar-zu-Bitcode
- lli test.bc zum JIT-Ausführen des Programms
- Fertig – Programm ist auf dem Bildschirm.
Keine Forward Declarations wie in C. Ich rufe was auf und deklariere oder definiere es hundert Zeilen später. Falls es aus WinAPI oder CRT kommt, findet der Compiler es ohne weiteres Zutun in den MinGW-Bibliotheken.
EIN TRAUM
Der weitere Plan ist:
- Ein halbes Jahr nur noch in LLVM Assembly programmieren
- LLVM Asm ist hässlicher als „normales“ Asm und drei Mal so viel Schreibarbeit; Hirn wird Matsche sein
- Eine Makro-Sprache im C-Stil hinklatschen, die mir alle nervigen Sachen abnimmt (z.B., dass man von jeder Variable nicht nur bei ihrer Deklaration, sondern auch bei jeder Benutzung explizit den Typ voranstellen muss)
- ???
- PERFEKTE SOFTWEAR UND NIE MEHR C++
Re: Anti-Jammer-Thread
H.265 erfüllt wohl die Erwartungen. Eine 0,57-fache Dateigröße bei vergleichbarer Bildqualität (Q=24).
(Und als reine Information, falls sich irgendjemand fragen sollte, wie er seine Videos überhaupt archivieren kann: FFV1.)
Ich für meinen Teil freue mich auf jedes Fitzelchen Gedankenfutter von deinem mutigen, neuen Pfad. ;)
(Und als reine Information, falls sich irgendjemand fragen sollte, wie er seine Videos überhaupt archivieren kann: FFV1.)
Krishty hat geschrieben:Der weitere Plan ist:
- Ein halbes Jahr nur noch in LLVM Assembly programmieren
- LLVM Asm ist hässlicher als „normales“ Asm und drei Mal so viel Schreibarbeit; Hirn wird Matsche sein
- Eine Makro-Sprache im C-Stil hinklatschen, die mir alle nervigen Sachen abnimmt (z.B., dass man von jeder Variable nicht nur bei ihrer Deklaration, sondern auch bei jeder Benutzung explizit den Typ voranstellen muss)
- ???
- PERFEKTE SOFTWEAR UND NIE MEHR C++
Ich für meinen Teil freue mich auf jedes Fitzelchen Gedankenfutter von deinem mutigen, neuen Pfad. ;)
- Krishty
- Establishment
- Beiträge: 8268
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Teile ich gern; auch wenn es im Augenblick wirklich fast nichts zu jammern gibt. Mich stört ein wenig, dass nativ nur ASCII-Strings unterstützt werden. Für das gute alte "foo" in UTF-16 muss man schreiben:eXile hat geschrieben:Ich für meinen Teil freue mich auf jedes Fitzelchen Gedankenfutter von deinem mutigen, neuen Pfad. ;)
@string = [4 x i16] { i16 102 i16 111 i16 111 i16 0}
Aber das müsste ich in Visual Studio auch, wenn ich meine Pläne von Strings ohne Nullterminierung umsetzen wollte. Mit linker_private_weak unnamed_addr davor kriege ich außerdem nicht nur String Pooling, sondern allgemeines Pooling mit allen Konstanten.
Auch sonst arbeitet es sich damit wahnwitzig gut, gemessen daran, dass man vor einem portablen Assembler sitzt! Als nächstes kommt Verbinden mehrerer Übersetzungseinheiten
- Schrompf
- Moderator
- Beiträge: 4884
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas Ziegenhagen
- Wohnort: Dresden
- Kontaktdaten:
Re: Anti-Jammer-Thread
In einer Stunde geht's auf's Summer Breeze. :-) Bin also weg bis Sonntag. So sehr ich mich darüber freue, endlich mal vor meinem Rechner wegzukommen, so sehr stört mich das aktuell auch, weil ich gerade so schön am Voxeltree schraube. Und vorhin kam gerade eine Nachricht rein, dass jemand ein Spielebundle mit (bekannteren) Indie-Spielen baut und gerne Splatter mit aufnehmen würde. Die Gamescom-Vorbereitungen rollen auch gerade unaufhaltsam... es ist eigentlich ein denkbar ungünstiger Zeitpunkt.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Re: Anti-Jammer-Thread
Hätte man das nicht zwischen Jammer- und Anti-Jammer-Thread splatten... äh splitten müssen? ;)Schrompf hat geschrieben:In einer Stunde geht's auf's Summer Breeze. :-) Bin also weg bis Sonntag. So sehr ich mich darüber freue, endlich mal vor meinem Rechner wegzukommen, so sehr stört mich das aktuell auch, weil ich gerade so schön am Voxeltree schraube. Und vorhin kam gerade eine Nachricht rein, dass jemand ein Spielebundle mit (bekannteren) Indie-Spielen baut und gerne Splatter mit aufnehmen würde. Die Gamescom-Vorbereitungen rollen auch gerade unaufhaltsam... es ist eigentlich ein denkbar ungünstiger Zeitpunkt.
Ohne Input kein Output.
Re: Anti-Jammer-Thread
Herzlichen Glückwunsch zum geglückten Umstieg.Krishty hat geschrieben:EIN TRAUM
Der weitere Plan ist:
- Ein halbes Jahr nur noch in LLVM Assembly programmieren
- LLVM Asm ist hässlicher als „normales“ Asm und drei Mal so viel Schreibarbeit; Hirn wird Matsche sein
- Eine Makro-Sprache im C-Stil hinklatschen, die mir alle nervigen Sachen abnimmt (z.B., dass man von jeder Variable nicht nur bei ihrer Deklaration, sondern auch bei jeder Benutzung explizit den Typ voranstellen muss)
- ???
- PERFEKTE SOFTWEAR UND NIE MEHR C++
Wenn's um eine Sprache geht, die nach LLVM-IR übersetzt wird, bin ich dabei. Am besten auch mit einem "Idiotensicher"-Modus, bei dem man bei den Entwicklern eine korrekte API-Nutzung erzwingen kann.
http://fedoraproject.org/ <-- freies Betriebssystem
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
- Krishty
- Establishment
- Beiträge: 8268
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Visual C++’ __assume() hat mich positiv überrascht.
Für Einsteiger: __assume() ist ein Hinweis an den Optimizer. Wenn ihr z.B. garantieren könnt, dass eine bestimmte Variable x niemals 3 überschreitet, schreibt ihr __assume(x <= 3);. Dann wird Visual C++ beim Inlining alle Pfade entfernen, die nur angesprungen werden, falls x größer als 3 wäre. Schreibt ihr vor einen Zeiger-Cast __assume(ptr != nullptr), dann kann der Compiler die Spezialfälle bei Nullzeiger-Casting ignorieren und performanteren Code erzeugen.
Am besten kann man davon Gebrauch machen, indem man seine assert()-Makros so anpasst, dass sie im Release-Modus durch __assume() ersetzt werden. Denn wenn ihr eh schon alle Invarianten eures Programms, die der Compiler nicht von allein erkennen kann, in assert() festhaltet, könnt ihr die Informationen auch dem Optimizer schenken, damit der mit diesem Wissen schnelleren Maschinentext erzeugt. So habe ich das auch gemacht.
Jedenfalls lief der frische Code eines Kollegen nicht mehr, sobald Optimierungen eingeschaltet wurden. Ich habe es ziemlich schnell auf diesen Quelltext eingrenzen können:
Object result = newAlgorithm();
Object oldResult;
#if defined _DEBUG
oldResult = oldAlgorithm__FOR_DEBUG_ONLY();
#endif
assert(result == oldResult);
In der Debug-Version wäre ein Hinweis gekommen, falls die neue Implementierung andere Ergebnisse liefert als die Alte. In der Release-Version hat Visual C++ allerdings gesehen:
Object result = newAlgorithm();
Object oldResult;
assert(result == oldResult);
und interpretiert:
Object oldResult;
… und schon hat die Release-Version nur noch uninitialisierten Speicher zurückgegeben.
Was mich dabei positiv überrascht: Object war ein POD-Datentyp. Normalerweise werden solche Hinweise nur für primitive Datentypen implementiert, weil die meisten Programmierer sie nur auf einzelne ints und Zeiger anwenden. Visual Studio hat aber offensichtlich implementiert, dass POD == POD Gleichheit aller Attribute bedeutet. Da hätte ich niemals drauf gewettet.
Für Einsteiger: __assume() ist ein Hinweis an den Optimizer. Wenn ihr z.B. garantieren könnt, dass eine bestimmte Variable x niemals 3 überschreitet, schreibt ihr __assume(x <= 3);. Dann wird Visual C++ beim Inlining alle Pfade entfernen, die nur angesprungen werden, falls x größer als 3 wäre. Schreibt ihr vor einen Zeiger-Cast __assume(ptr != nullptr), dann kann der Compiler die Spezialfälle bei Nullzeiger-Casting ignorieren und performanteren Code erzeugen.
Am besten kann man davon Gebrauch machen, indem man seine assert()-Makros so anpasst, dass sie im Release-Modus durch __assume() ersetzt werden. Denn wenn ihr eh schon alle Invarianten eures Programms, die der Compiler nicht von allein erkennen kann, in assert() festhaltet, könnt ihr die Informationen auch dem Optimizer schenken, damit der mit diesem Wissen schnelleren Maschinentext erzeugt. So habe ich das auch gemacht.
Jedenfalls lief der frische Code eines Kollegen nicht mehr, sobald Optimierungen eingeschaltet wurden. Ich habe es ziemlich schnell auf diesen Quelltext eingrenzen können:
Object result = newAlgorithm();
Object oldResult;
#if defined _DEBUG
oldResult = oldAlgorithm__FOR_DEBUG_ONLY();
#endif
assert(result == oldResult);
In der Debug-Version wäre ein Hinweis gekommen, falls die neue Implementierung andere Ergebnisse liefert als die Alte. In der Release-Version hat Visual C++ allerdings gesehen:
Object result = newAlgorithm();
Object oldResult;
assert(result == oldResult);
und interpretiert:
- result wird zurückgegeben.
- result und oldResult müssen denselben Wert enthalten, sagt der Programmierer.
- oldResult ist wesentlich einfacher zu berechnen als result, weil der fette Funktionsaufruf fehlt.
- Der newAlgorithm() ändert auch keine globalen Variablen und ruft keine externen Funktionen auf.
- Da beide zum selben Ergebnis führen, ist es deutlich schneller, sich für oldResult zu entscheiden.
Object oldResult;
… und schon hat die Release-Version nur noch uninitialisierten Speicher zurückgegeben.
Was mich dabei positiv überrascht: Object war ein POD-Datentyp. Normalerweise werden solche Hinweise nur für primitive Datentypen implementiert, weil die meisten Programmierer sie nur auf einzelne ints und Zeiger anwenden. Visual Studio hat aber offensichtlich implementiert, dass POD == POD Gleichheit aller Attribute bedeutet. Da hätte ich niemals drauf gewettet.
- Krishty
- Establishment
- Beiträge: 8268
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
- Schrompf
- Moderator
- Beiträge: 4884
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas Ziegenhagen
- Wohnort: Dresden
- Kontaktdaten:
Re: Anti-Jammer-Thread
Sehr schönes Bild. Wo genau ist das Questmonster? Das können Sie unmöglich übersehen.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Re: Anti-Jammer-Thread
Sind die Bäume Sprites?
http://fedoraproject.org/ <-- freies Betriebssystem
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
- Krishty
- Establishment
- Beiträge: 8268
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Stand da bereits hinter mir.Schrompf hat geschrieben:Sehr schönes Bild. Wo genau ist das Questmonster? Das können Sie unmöglich übersehen.
Das werde ich morgen früh nachgucken.antisteo hat geschrieben:Sind die Bäume Sprites?
- CodingCat
- Establishment
- Beiträge: 1857
- Registriert: 02.03.2009, 21:25
- Wohnort: Student @ KIT
- Kontaktdaten:
Re: Anti-Jammer-Thread
Duane Merrill, der Entwickler der Back40Computing CUDA-Bibliothek, arbeitet inzwischen bei NVIDIA an CUB. Mit dessen aktuellen Release ändert sich meine Empfehlung für die mit Abstand schnellste verfügbare Radix-Sort-Implementierung nun von B40C zu CUB. Hat bei mir die Sortierzeit eben von 11 ms weiter auf 7 ms gedrückt. Wenn das mal kein Speedup ist, nur durch Software!
Leider heißt das auch, dass eine kompetitive Sortierimplementierung in HLSL für mich jetzt in noch weitere Ferne rückt. Mein bestes Ergebnis in einer OpenCL-Testimplementierung war zuletzt 14 ms, also nun schon das Doppelte der bestmöglichen Zeit. :-/
Leider heißt das auch, dass eine kompetitive Sortierimplementierung in HLSL für mich jetzt in noch weitere Ferne rückt. Mein bestes Ergebnis in einer OpenCL-Testimplementierung war zuletzt 14 ms, also nun schon das Doppelte der bestmöglichen Zeit. :-/
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Re: Anti-Jammer-Thread
Irgendwie macht es Spaß, wenn man Leute glücklich macht, indem man ihnen ihren Drucker unter Windows einrichtet und dafür genau so viel Geld (oder mehr) wie fürs Programmieren bekommt. Vielleicht ändere ich irgendwann mein Lebenskonzept und werde Außendienstmitarbeiter.
http://fedoraproject.org/ <-- freies Betriebssystem
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
- Krishty
- Establishment
- Beiträge: 8268
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Die Druckerindustrie ist eine der verlogensten überhaupt; darum würde es mich nicht wundern, wenn bis heute kein WIRKLICH Plug'n'Play-tauglicher Drucker aus eben dem Grund existiert, dass solche sogenannten "Arbeitsplätze" damit vernichtet würden.
- kimmi
- Moderator
- Beiträge: 1405
- Registriert: 26.02.2009, 09:42
- Echter Name: Kim Kulling
- Wohnort: Luebeck
- Kontaktdaten:
Re: Anti-Jammer-Thread
Schon mal einen Drucker unter Linux mit Cups zum Laufen gebracht? :) Das kommt gleich nach X11 / Wayland in der Konsole konfigurieren.
Gruß Kimmi
Gruß Kimmi
- Chromanoid
- Moderator
- Beiträge: 4263
- Registriert: 16.10.2002, 19:39
- Echter Name: Christian Kulenkampff
- Wohnort: Lüneburg
Re: Anti-Jammer-Thread
Hab ich gerade bei reddit gesehen, fand ich sehr interessant und hat mich irgendwie an Dich erinnert, Krishty :D
http://www.chrissawyergames.com/faq3.htmWhat language was RollerCoaster Tycoon programmed in?
It's 99% written in x86 assembler/machine code (yes, really!), with a small amount of C code used to interface to MS Windows and DirectX.
- Krishty
- Establishment
- Beiträge: 8268
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Ja; die Grand Prix-Serie wurde auch von Geoff Crammond fast komplett in Assembler geschrieben.
LLVM Assembly ist für mich weiterhin ein Experiment bis ich es vollständig begriffen habe; aber langfristig plane ich, C++ nur noch für Prototyping zu benutzen.
LLVM Assembly ist für mich weiterhin ein Experiment bis ich es vollständig begriffen habe; aber langfristig plane ich, C++ nur noch für Prototyping zu benutzen.
- Chromanoid
- Moderator
- Beiträge: 4263
- Registriert: 16.10.2002, 19:39
- Echter Name: Christian Kulenkampff
- Wohnort: Lüneburg
Re: Anti-Jammer-Thread
:(Geoff Crammond hat geschrieben:Allerdings bin ich der Einzige, der meinen Code lesen und verändern kann. Ich kann es mir also nicht leisten, jemals krank zu werden.