|
|
|
|
|
|
|
Naja du hast einen Basis Pointer, angenommen 0x00412345.
Der zeigt dann wiederum auf eine andere Addresse
0x00400001 -> 0x00400002
und der wiederum auf eine andere
0x00400000 -> 0x00400008 -> 0x0040000F
und der wiederum auf eine andere
0x00400000 -> 0x00400008 -> 0x0040000F -> 0x004000017
und bei der ließt du dann den Wert als Int aus.
Mit den Offsets dann eben
0x00400000 -> 0x00400008(+0x8) -> 0x0040000F(+0x4) -> 0x004000017
usw 
|
|
|
|
|
|
|
|
|
|
|
|
Bäh meint MS das mit der scheiss Win8 Oberfläche eigentlich ernst? -_-
|
|
|
|
|
|
|
|
|
|
|
Jemand Ahnung von Pixel Buffer Objects in OpenGL?
Ich muss 30*5 Texturen pro Sekunde laden, und das Problem ist das OpenGL den Thread blockt bis die Texturen fertig geladen sind weswegen die FPS brutal einbrechen (~15 FPS, ich brauche > 30 - am besten natürlich so schnell es geht). ¤: Das ganze ist in C++ geschrieben.
Mit PBOs kann man nun scheinbar asynchron die Texturdaten zur Grafikkarte schaufeln und gleichzeitig den Umweg über den RAM vermeiden, den man soweit ich das rausgefunden habe mit "konventionellem" OpenGL hat, was nochmal mehr Performance bringt.
Der Punkt ist - ich finde genug Literatur wie man einzelne Texturen an einen PBO bindet, aber das hilft mir nicht so richtig weiter.
Ich müsste nämlich 5 Texturen an ein PBO binden, dass dann in meinen Shader schaufeln und auf ein Quad mappen. Und genau an dem Punkt scheitere ich gerade Mental: Die Verbindung mehrere Texturen im PBO, Pixel Shader und das ganze auf ein Quad mappen.
Achja erschwerend kommt natürlich zu, dass ich in einen PBO meine Texturdaten laden müsste, während OpenGL aus einem anderen ausliest und rendert. Wenn der Upload der Texturdaten fertig ist werden die beiden PBOs geswitcht.
Soweit die Theorie. 
Hat da zufällig jemand Ahnung von oder etwas Literatur, bei der nicht in nur 5 Zeilen ein paar OpenGL calls hingerotzt wurden?
¤: Eine andere Idee wäre natürlich das Texturladen einfach in einen anderen Thread auszulagern, aber dann müsste ich die synchronisieren und hätte wegen einer Threading Library eine weitere Dependency. Das würde ich gerne vermeiden.
| | Zitat von Noch_ein_Kamel
Bäh meint MS das mit der scheiss Win8 Oberfläche eigentlich ernst? -_-
| |
Sowas wie Metro kommt halt dabei raus, wenn man sich auf ein einheitliches Interface Tablet/Handy <-> PC versteift. Für ein Tablet mag das ja ganz toll sein. Aber auf dem PC...
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von AcidF!re am 18.04.2012 22:43]
|
|
|
|
|
|
|
|
|
| | Zitat von CLiX
Naja du hast einen Basis Pointer, angenommen 0x00412345.
Der zeigt dann wiederum auf eine andere Addresse
0x00400001 -> 0x00400002
und der wiederum auf eine andere
0x00400000 -> 0x00400008 -> 0x0040000F
und der wiederum auf eine andere
0x00400000 -> 0x00400008 -> 0x0040000F -> 0x004000017
und bei der ließt du dann den Wert als Int aus.
Mit den Offsets dann eben
0x00400000 -> 0x00400008(+0x8) -> 0x0040000F(+0x4) -> 0x004000017
usw
| |
Ja *was* da passiert ist schon klar, bloss, das "warum"... wie oft ist das technische Design denn vorher vom Bus gestreift worden, dass da sowas bei herauskommt?
|
|
|
|
|
|
|
|
|
|
|
Weil ich auf den Speicher nur über den Weg Zugriff hab
Bot für'n Spiel, weischte.
|
|
|
|
|
|
|
|
|
|
|
Ja klar, aber ich haette mir da doch schon laengst ein paar structs definiert, die dem Speicherlayout der Objekte entsprechen, auf die du da zugreifst? Also sowas:
#pragma pack(push, 1)
struct enemystate_packed
{
int crap;
uint8_t pad1[4];
int ID; // + 0x0008
unsigned short X; // + 0x000C
unsigned short Y; // + 0x000E
uint8_t pad2[0xA0];
uint8_t HP; // + 0x00B0
uint8_t MP; // + 0x00B1
uint8_t pad3[0x75];
uint8_t Used; // + 0x0127
};
#pragma pack(pop)
Dann castest du deinen Zeiger da einmal nach enemystate_packed* und kannst dann einfach ueber es->X , es->HP etc. auf die Felder zugreifen. Ebenso mit den Zwischenstufen, ueber die du oben dereferenzierst. Ich meine, wenn sich da irgendwann mal das Speicherlayout aendern sollte oder das jemand anders nachvollziehen muss, wird das ganze Ding doch so fragil wie nur irgendwas.
|
|
|
|
|
|
|
|
|
|
|
|
Was verdient man eigentlich mit Bots denn so? Habe mich schon immer gefragt wieviel den ganzen Bescheissern solch ein high-level e-peen monetaer wert ist
|
|
|
|
|
|
|
|
|
|
|
Gerade mal geguckt, einen Diablo2-Bot gibts für 45 Euro. Jetzt noch. Ich würde sagen, man kann ganz gut davon leben 
|
|
|
|
|
|
|
|
|
|
|
Ouch :
| | Hallo!
Du bekommst diese E-Mail, da ein Account mit dieser Adresse auf einer Seite der Computec Media AG existiert. Es erfolgte in den letzten Tagen ein Hacker-Angriff auf unsere Seiten, den wir in Zusammenarbeit mit einem externen IT-Sicherheitsexperten vollständig analysiert haben. Als sofortige Gegenmaßnahme wurden zuerst die Downloads deaktiviert und entdeckte Lücken im System geschlossen, trotzdem ist eine Gefährdung des eigenen PC möglich.
Was ist passiert?
Durch einen Angriff auf unsere Webseiten wurde Malware verteilt, die möglicherweise nicht von aktuellen Virenscannern erkannt wurde
Passwörter wurden möglicherweise direkt auf den Servern oder auf dem eigenen PC gestohlen
Die Angriffe fanden insbesondere an den letzten beiden Wochenenden statt (07.-08.04.12, 14.-15.04.12).
Nicht betroffen sind der Computec-Shop (shop.computec.de) sowie die Abonnenten-Daten.
Was muss ich tun?
Das eigene System auf Malware überprüfen. Hier können Sie kostenlose Sicherheits-Tools nutzen, wie sie beispielsweise auf http://www.heise.de/download/f-secure-rescue-cd.html oder http://www.heise.de/download/bitdefender-rescue-cd.html verfügbar sind.
Sie sollten sämtliche Passörter (insbesondere PayPal, Ebay, Facebook) ändern (dies empfiehlt sich auch auf Systemen, auf denen kein Virenalarm ausgelöst wird)
Schritt 1 (Virenscan) ist dabei unbedingt vor dem Ändern der Passwörter durchzuführen!
Seit Montag berichten wir regelmäßig und aktualisiert auf den Webseiten und im Forum. Zur Sicherheit verschicken wir diese Information auch E-Mail. Mehr Informationen finden sich auf PCGames.de, Buffed.de, Videogameszone.de, Gamesaktuell.de und PCGameshardware.de.
Wir bitten um Entschuldigung für die entstandenen Unannehmlichkeiten und werden den Vorfall selbstverständlich umfangreich aufarbeiten.
Das Computec-Team | |
|
|
|
|
|
|
|
|
|
|
|
|
Das Forum hier hat nichts mehr mit PCGames zu tun, oder?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fu.
|
|
|
|
|
|
|
|
|
|
|
Ach, Scheisse, fuer das bisschen Geld sollte er sich lieber mit iOS/Android befassen. Es gibt alleine 200 Millionen aktive Android-Geraete bzw. potenzielle Kunden. Bescheissen und Bescheisser-Programme schreiben fuer das bisschen Kohle ist doch gleichermassen asozial 
Jung, mach was aus Deinem Leben und befriedige die ganzen Smartphone-Freier fuer 79 Eurocent!
Eine "Kann-nicht-ohne-Killerapp-fuer-79-Cent" bei 1% Marktpenetration (2 Millionen Kaeufe) bietet 1,106,000 gute Gruende mit dem Bescheissen aufzuhoeren; nach Abzug der 30%-Google-Provision
|
|
|
|
|
|
|
|
|
|
|
|
*Gluck gluck gluck* ahhhh
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Noch_ein_Kamel
Bäh meint MS das mit der scheiss Win8 Oberfläche eigentlich ernst? -_-
| |
Naja. Ist man von Microsoft doch gewöhnt, dass jedes zweite Betriebssystem scheiße wird. ME anyone?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Strider
Ach, Scheisse, fuer das bisschen Geld sollte er sich lieber mit iOS/Android befassen. Es gibt alleine 200 Millionen aktive Android-Geraete bzw. potenzielle Kunden. Bescheissen und Bescheisser-Programme schreiben fuer das bisschen Kohle ist doch gleichermassen asozial
Jung, mach was aus Deinem Leben und befriedige die ganzen Smartphone-Freier fuer 79 Eurocent!
Eine "Kann-nicht-ohne-Killerapp-fuer-79-Cent" bei 1% Marktpenetration (2 Millionen Kaeufe) bietet 1,106,000 gute Gruende mit dem Bescheissen aufzuhoeren; nach Abzug der 30%-Google-Provision
| |
Android: Scheitert an Java.
iOS: Scheitert am Mac
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von igor]2
Ja klar, aber ich haette mir da doch schon laengst ein paar structs definiert, die dem Speicherlayout der Objekte entsprechen, auf die du da zugreifst? Also sowas:
...
Dann castest du deinen Zeiger da einmal nach enemystate_packed* und kannst dann einfach ueber es->X , es->HP etc. auf die Felder zugreifen. Ebenso mit den Zwischenstufen, ueber die du oben dereferenzierst. Ich meine, wenn sich da irgendwann mal das Speicherlayout aendern sollte oder das jemand anders nachvollziehen muss, wird das ganze Ding doch so fragil wie nur irgendwas.
| |
Einfach irgendwelche Speicherzellen über die Adresse auszulesen ist echt nasty: Fehleranfällig, gefährlich und eklig zugleich. Das mit dem Struct ist eine coole Idee. Aber, gibt einem der Compiler da eine Garantie, dass die Elemente auch in der definierten Reihenfolge im Speicher stehen? Oder wird da vielleicht kaputtoptimiert?
|
|
|
|
|
|
|
|
|
|
|
Die Garantie ueber die Reihenfolge gibt C++ dir.
Die einzige Garantie, die du normalerweise nicht hast, ist das Alignment -- der Compiler darf/wird Komponenten eines Structs i.d.R. weiter auseinanderruecken, um z.B.(!) sicherzustellen, dass Komponenten immer auf Speicheradressen zu liegen kommen, die mindestens durch die Groesse eines DWORD (4 Bytes) oder der Groesse ihres eigenen Typs teilbar sind.
Dadurch entstehen zwischen diesen Komponenten dann evtl. "Leerraeume" im Speicher, was zwar etwas Platz verschwendet, aber den Zugriff auf diese Elemente beschleunigt.
#pragma pack setzt hier das Alignment aber explizit auf 1 (Byte), womit das Gesamtlayout im Speicher fix ist.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von CLiX
Android: Scheitert an Java.
| |
Was ist dann jetzt an Java schlimm? Google brauchte eben eine Sprache mit hoher Marktdurchdringung die relativ viel kann und halbwegs sauber zu verwenden ist und die auf einer VM läuft und gleichzeitg nicht properitär gedeckelt ist.
Was bleibt denn da noch?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Achsel-des-Bösen
| | Zitat von CLiX
Android: Scheitert an Java.
| |
Was ist dann jetzt an Java schlimm? Google brauchte eben eine Sprache mit hoher Marktdurchdringung die relativ viel kann und halbwegs sauber zu verwenden ist und die auf einer VM läuft und gleichzeitg nicht properitär gedeckelt ist.
Was bleibt denn da noch?
| |
naja, objective-C erfüllt jetzt nicht umbedingt die kriterien, und apple hat trotzdem erfolg damit, das allen aufzuzwingen.
wenn ich mir innerhalb von ein paar minuten was einfallen lassen müsste, hätte ich es mit einer statisch typisierten variante (type inference, damit man kaum typannotationen angeben muss) von javascript ohne das ganze reflection-zeug, aber mit einem java/c++/python-mäßigem klassensystem probiert: das ist kompilierbar (=schnell), das ist kein großer umstieg für webdeveloper und gar keiner für flash-programmierer, und außerdem voll modern und so.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von flying sheep am 19.04.2012 10:18]
|
|
|
|
|
|
|
|
|
|
WebOS hat ja weitestgehend auf so einen Ansatz vertraut, also so ganz abwegig ist das nicht.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von flying sheep
wenn ich mir innerhalb von ein paar minuten was einfallen lassen müsste....
| |
So früh schon falsch abgebogen, denn du kannst so eine Plattform nicht einfach neu erfinden und hoffen das die Community darum schon selbst an den Haaren aus dem Sumpf herauszieht. Seien wir doch mal ehrlich, wenn wir eins aus der kurzen Geschichte der mobilen Umgebungen gelernt haben, dass, dass es nur klappt, wenn eine begeisterte Entiwcklerschaft Apps wie am Fließband produziert. Ohne Apps ist Android == iOS == Windows Phone == WebOS, der Unterschied kommt erst durch das Ökosystem.
Um an so eine Community zu kommen brauchst du imho zwei Dinge: Eine coole, möglichst wenig restriktive Plattform und gescheiten Toolsupport. Die ursprünge von Android datieren um 2003, zu dem Zeitpunkt war Java schon bei Version 1.4 und 1.5 stand vor der Tür. Da gab es schon massenhaft Tools für jeden erdenklichen Einsatzzweck. Und sowas will man natürlich nutzen.
Wenn man sowas einfach auf der grünen Wiese plant, dann gibt es nichts davon, sondern alles muss erst von vorne entwickelt werden. Und das killt den Bootstrap Prozess der Community, weil sie nichts damit beschäftigt sind Apps zu produzieren, damit du deinen Scheiss verkaufen kannst, sondern sich (wenn überhaupt) ans Werk machen und Tools schreiben, die sie haben wollen.
Wobei ich dir in so fern recht gebe als das man sowas heutzutage vermutlich auf Javascript stellen würde (was ich nicht gut fände, Javascript ist für mich kein Beispiel einer gut designten Sprache). Wobei man sowas natürlich heutzutage komplett vergessen kann, weil der Markt auf die nächsten Jahre komplett überfüllt ist.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Achsel-des-Bösen am 19.04.2012 11:07]
|
|
|
|
|
|
|
|
|
Oh, falls jemand meine Voraussage für die Zukunft der Smartphones interessiert (wir könne ja auf Seite 10- oder 15000 mal nachgucken  ):
Microsoft wirds nichts packen. Die waren (wie schon beim Zune) zu spät. Noch 1-3 Jahre und dann dürfte sich das erledigt haben. Es sei denn sie lassen sich irgendwas unglaublich geniales Einfallen. Aber da glaube ich nicht dran, Microsoft ist nicht der Konzern für geniale Einfälle.
Apple hat zwei Möglichkeiten: Entweder sie machen alles richtig und werden ihren Marktanteil noch ein klein wenig ausbauen und dann da verweilen oder (wahrscheinlicher) sie bauen Mist. Seht es so: Es ist nur eine Firma und jede größere strategische Entscheidung hat eine gewisse "fail"-Chance. Je mehr strategisch Entscheidungen desto höher wird die Wahrscheinlichkeit das irgendwann mal eine schiefgeht. Der durchschnittliche Applekäufer (abseits des totalen Fanbois) ist, zumindest in meinen Augen, leicht zu verärgern und würde dann vermutlich gehen.
Android...hm...Android sollte es eigentlich auch nicht packen. Zu viele Unterschiede, zu großé Zerstückelung des Marktes. Irgendwann muss den Kunden klar werden, dass sowas nicht gut ist und da sollten abwandern. Allerdigngs steht die Zerstückelung auch auf der Pro-Seite, denn hinter Android stehen ein Haufen Firmen und ein Haufen Kohle, also sollte das Android Ökosystem länger durchhalten. Schwierig, schwierig.
|
|
|
|
|
|
|
|
|
|
|
Ich sitze hier in der Hochschule in einem Gruppenarbeitsraum...hier ist seit letzter Woche eine neue Arbeitsgruppe...die sich ein wenig mit "Internetsicherheit" als Projekt beschäftigen...
Jetzt haben Sie herausgefunden, dass man 99% des HTTP-Traffics PlainText abgreifen kann...und schwirren seit ner gefühlten halben Stunde im Internet umher und wundern sich, das Sie am laufenden Band die Logindaten abfangen können... *facepalm*
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Achsel-des-Bösen
| | Zitat von CLiX
Android: Scheitert an Java.
| |
Was ist dann jetzt an Java schlimm? Google brauchte eben eine Sprache mit hoher Marktdurchdringung die relativ viel kann und halbwegs sauber zu verwenden ist und die auf einer VM läuft und gleichzeitg nicht properitär gedeckelt ist.
Was bleibt denn da noch?
| |
Ich hab das jetzt so interpretiert, dass er keine Ahnung von Java hat.
Ansonsten gilt: Nur weil Sheep gegen etwas ist, spricht das noch lange nicht gegen die Verwendung. Schon gar nicht bei Java. :P
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Achsel-des-Bösen
Oh, falls jemand meine Voraussage für die Zukunft der Smartphones interessiert (wir könne ja auf Seite 10- oder 15000 mal nachgucken ):
Microsoft wirds nichts packen. Die waren (wie schon beim Zune) zu spät. Noch 1-3 Jahre und dann dürfte sich das erledigt haben. Es sei denn sie lassen sich irgendwas unglaublich geniales Einfallen. Aber da glaube ich nicht dran, Microsoft ist nicht der Konzern für geniale Einfälle.
Apple hat zwei Möglichkeiten: Entweder sie machen alles richtig und werden ihren Marktanteil noch ein klein wenig ausbauen und dann da verweilen oder (wahrscheinlicher) sie bauen Mist. Seht es so: Es ist nur eine Firma und jede größere strategische Entscheidung hat eine gewisse "fail"-Chance. Je mehr strategisch Entscheidungen desto höher wird die Wahrscheinlichkeit das irgendwann mal eine schiefgeht. Der durchschnittliche Applekäufer (abseits des totalen Fanbois) ist, zumindest in meinen Augen, leicht zu verärgern und würde dann vermutlich gehen.
Android...hm...Android sollte es eigentlich auch nicht packen. Zu viele Unterschiede, zu großé Zerstückelung des Marktes. Irgendwann muss den Kunden klar werden, dass sowas nicht gut ist und da sollten abwandern. Allerdigngs steht die Zerstückelung auch auf der Pro-Seite, denn hinter Android stehen ein Haufen Firmen und ein Haufen Kohle, also sollte das Android Ökosystem länger durchhalten. Schwierig, schwierig.
| |
den Durchschnittsanwender interessiert doch nicht, dass es einen Haufen unterschiedlicher Android-Geräte gibt. Die wollen nur, dass ihr eigenes Gerät funktioniert. Die Entwickler werden da noch drunter zu leiden haben, aber das war früher auf dem PC nicht anders. Die App-Entwicklung scheint bisher nicht allzu sehr darunter zu leiden und die Plattform wird sich dahingehend vermutlich auch noch verbessern.
Früher gabs halt Sony mit eigener Oberfläche, Samsung mit eigener Oberfläche, Windows Mobile, Nokia zuerst mit den alten Business-Brocken, dann mit verschiedenen Symbian-Varianten und dazu noch einen Haufen kleinerer Hersteller, die auch jeder ein eigenes Süppchen gekocht haben. Damals waren die Geräte zwar deutlich fokussierter auf Telefon und SMS, aber im Grunde gehts immer nur darum, die Bedienung einfach zu gestalten.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GH@NDI
Ich sitze hier in der Hochschule in einem Gruppenarbeitsraum...hier ist seit letzter Woche eine neue Arbeitsgruppe...die sich ein wenig mit "Internetsicherheit" als Projekt beschäftigen...
Jetzt haben Sie herausgefunden, dass man 99% des HTTP-Traffics PlainText abgreifen kann...und schwirren seit ner gefühlten halben Stunde im Internet umher und wundern sich, das Sie am laufenden Band die Logindaten abfangen können... *facepalm*
| |
Das geht hier im Hörsaal auch, weil die Leute zu (faul|dumm) sind das gesicherte WLAN zu nutzen, bei dem man Nutzername/Passwort halt schon vor dem Verbindungsaufbau eingeben muss, und nicht erst auf einer Loginseite.
|
|
|
|
|
|
|
|
|
|
|
|
Funfact(TM): Via VPN kann man sich einloggen.
|
|
|
|
|
|
|
|
|
|
|
|
Wie VPN wohin?
|
|
|
|
|
|
|
|
| Thema: Gehirnsalat ( wir unter uns ) |
![[Dicope]](./avatare/drkleiner.gif)
