Nein:
Nun bekommt jeder aber nur 1€ zurück, weil der Typ sich 2 einsteckt. Also bezahlen die Jungen 28€. Davon bezahlt jeder Junge 9,333€
Er steckt sich 2 ein und gibt insgesamt 3 Euro zurück. Das heißt, die Jungen zahlen 27 €, also 9 pro Person.
Nein:
Nun bekommt jeder aber nur 1€ zurück, weil der Typ sich 2 einsteckt. Also bezahlen die Jungen 28€. Davon bezahlt jeder Junge 9,333€
Er steckt sich 2 ein und gibt insgesamt 3 Euro zurück. Das heißt, die Jungen zahlen 27 €, also 9 pro Person.
Ähh, nein.
Du hast ausgerechnet, wie viel Geld jeder bezahlt hätte bei 25 Euro. Dann hast du jedem einen Euro hinzugererchnet.
Die Aufgabe geht von 30 Euro aus (jeder 10 Euro). Da sich 5 Euro schlecht aufteilen lassen, gibt der Hotelbesitzer 3 Euro, also jedem 1 zurück. Jeder hat 9 Euro bezahlt.
Der Fehler der Ausgabe lag darin, dass 3*9 = 27 Euro (das Geld der Jungen) + 2 Euro (Hotelbesitzer) = 29 macht.
Der Fehler darin ist, dass die 27 Euro, die die Jungen bezahlt haben, bereits die 2 Euro zu viel enthält. Würde man stattdessen von 27 Euro 2 abrechnen, käme man auf 25, also genau der wirkliche Preis des Zimmers.
Der Gewinner ist der Sohn meines Physiklehrers und er hat zusammen mit anderen Teilnehmern den Code veröffentlicht.
Ich finde, du solltest einen eigenen Wettbewerb ausdenken und nicht einfach nur übernehmen.
Es gefällt mir garnicht, dass man nur eine Funktion definieren darf. Dadurch entsteht nur schlechter Spaghetticode und die Übersichtlichkeit beim Schreiben geht auch verloren.
Ich bin bei AI-Contests gerne dabei, aber nicht zu den Bedingungen.
Ich finde die Umsetzung auch nicht gut, weil man $ setzen kann, es aber ignoriert wird.
[autoit]Global a=10
MsgBox(0, "", $a)
Hierbei wird $a und a identisch und man kann den Zusammenhängende nicht so schnell erkennen.
Der Bruch ist dennoch notwendig, da Variablen neuerdings Funktionen beinhalten können. Die Verwendung von
[autoit]Global $function=ConsoleWrite
$function("Hallo")
würde auch einen Bruch darstellen, da nun Funktionen auch mit Dollarzeichen deklariert werden können.
Auf längere Sicht wünsche ich die Entwicklung so, dass Funktionen zu normalen Variablen werden, wie in LUA.
Nächstes Gegenbeispiel:
Switch $s_Input
Case "Mo"
$s_Tag = "Montag"
Case "Di"
$s_Tag = "Dienstag"
Case "Mi"
$s_Tag = "Mittwoch"
Case "Do"
$s_Tag = "Donnerstag"
Case "Fr"
$s_Tag = "Freitag"
Case "Sa"
$s_Tag = "Samstag"
Case "So"
$s_Tag = "Sonntag"
Case Else
$s_Tag = "Fehlerhaft"
EndSwitch
Wenn man assoziative Arrays hätte (wie z.B. bei Pyton oder lua), könnte man das damit noch schneller und einfacher lösen.
Ja. In diesem Beispiel kommt das gleiche raus.
In vielen Sprachen ist auch der goto-Befehl implementiert und man braucht ihn eigentlich nie.
Ich hab nicht viel gegen den Operator an sich, auch wenn ich ihn fast nie brauche. Mich stört aber die Art, wie er implementiert wird.
Eine Programmiersprache sollte möglichst gut lesbar sein und dadurch, dass ein Fragezeichen und ein Doppelpunkt verwendet werden, gibt es gleich zwei Hindernisse dabei.
In Python hingegen ist die Implementierung in Ordnung, da man mit den lesbaren Keywords if und else auskommt.
Es ist ein Sprachfeature welches man nutzen kann - oder eben nicht. "Brauchen" ist da das falsche Wort.
"Umso mehr, desdo besser" gilt bei Programmiersprachen nicht. Es ist oft besser, die Sprachfeatures zu beschränken, damit die Programmierer gezwungen werden, gut lesbaren Code zu schreiben.
[autoit]
Aber da ich nun auf die Beta 3.3.9.5 aufmerksam geworden bin hab ich noch entdeckt das endlich der ternäre Operator eingeführt wurde.
Wer schon bisschen was in C geschrieben hat der wird diesen Operator sehr liebengelernt haben da er den Code so schön kurz und absolut unleserlich machen kann ;):$bResult = ("foo" = "bar") ? False : True
[/autoit]
Braucht man das wirklich? Das macht den Code nur komplizierter und ich habe es bisher noch nie verwendet. Und wenn man es unbedingt braucht, dann gibt doch schon die Funktion _Iif.
Ich hätte sehr gerne für AutoIt-Code ein try-catch System. Das macht den Code deutlich übersichtlicher und einfacher.
Kann man dafür auch Shader programmieren?
1) Sieh dir einfach mal die Irrlicht-Beispiele an. Zumindest in der C++-Version gibt es da einige, aus denen man sich schon eine einfache Art Shooter zusammenbasteln kann. Es gibt da eine typische Camerasteuerung, Schwerkraft, Kollision mit dem Boden, Schüsse mit Rauchentwicklung beim Auftreffen.
Dann gibt es auch keine KI, kein Wegnetz.
2) Blender. Zum Zusammenbasteln der Welt empfehle ich irrEdit.
Man darf doch so viele Variablen verwenden, wie man will, solange sie booleans sind, oder? Sind arrays auch in Ordnung?
Ich mache gerne mit.
#include "..\au3Irrlicht2.au3"
[/autoit] [autoit][/autoit] [autoit]HotKeySet("{ESC}", "_exit")
[/autoit] [autoit][/autoit] [autoit]Func _exit()
_IrrStop()
Exit
EndFunc ; _exit
Global $ROWS_AND_COLUMNS = 40
Global $hLOD2Mesh
Global $iAmountNodes = $ROWS_AND_COLUMNS * $ROWS_AND_COLUMNS
Global $aSceneNodes[$iAmountNodes]
Global $hMaterial
Global $k = 0
Global $hLODManager
Global $hCamera
_IrrStart( $IRR_EDT_OPENGL, 800, 600, $IRR_BITS_PER_PIXEL_32, _
$IRR_WINDOWED, $IRR_SHADOWS, $IRR_IGNORE_EVENTS, $IRR_VERTICAL_SYNC_ON )
$hLOD2Mesh = _IrrGetMesh("../media/cube.x")
local $sceneNode = _IrrAddMeshToScene( $hLOD2Mesh )
_IrrScaleMesh($hLOD2Mesh, 2.0)
_IrrSetMeshHardwareAccelerated($hLOD2Mesh)
$texture = _IrrGetTexture("../media/Cross.bmp")
For $i = -($ROWS_AND_COLUMNS / 2) To ($ROWS_AND_COLUMNS / 2) - 1
[/autoit] [autoit][/autoit] [autoit]For $j = -($ROWS_AND_COLUMNS / 2) To ($ROWS_AND_COLUMNS / 2) - 1
$aSceneNodes[$k] = _IrrAddMeshToScene($hLOD2Mesh)
_IrrSetNodeName($aSceneNodes[$k], "ground")
_IrrSetNodePosition($aSceneNodes[$k], $i * 5.0, 0.0, $j * 5.0)
_IrrSetNodeMaterialTexture($aSceneNodes[$k], $texture, 0)
_IrrSetNodeMaterialFlag($aSceneNodes[$k], $IRR_EMF_LIGHTING, $IRR_ON)
$hMaterial = _IrrGetMaterial($aSceneNodes[$k], 0)
_IrrMaterialVertexColorAffects($hMaterial, $ECM_NONE)
_IrrMaterialSetAmbientColor($hMaterial, 255, 255, 255, 255)
_IrrMaterialSetDiffuseColor($hMaterial, 255, 255, 255, 255)
$k += 1
Next
Next
$hLODManager = _IrrAddLODManager(2, $IRR_off)
_IrrSetLODMaterialMap($hLODManager, $IRR_EMT_TRANSPARENT_ADD_COLOR, $IRR_EMT_TRANSPARENT_ADD_COLOR)
_IrrAddLODMesh($hLODManager, 600.0, $hLOD2Mesh)
_IrrSetNodeMaterialFlag($hLODManager, $IRR_EMF_LIGHTING, $IRR_OFF)
For $i = 0 To $k - 1
_IrrAddChildToParent($aSceneNodes[$i], $hLODManager)
Next
[/autoit] [autoit][/autoit] [autoit][/autoit] [autoit]$Camera = _IrrAddFPSCamera()
$CameraNode = $Camera
$CombinedCollision = _IrrCreateCombinedCollisionGroup ()
For $i=0 To $iAmountNodes-1
$SelectorGround = _IrrGetCollisionGroupFromBox( $aSceneNodes[$i] )
_IrrAddCollisionGroupToCombination ( $CombinedCollision, $SelectorGround )
Next
$CollisionAnimator = _IrrAddCollisionAnimator( _
$CombinedCollision, $CameraNode, _
1.0,1.0,1.0, _
0.0,-0.2,0.0, _
0.0,1.0,0.0 )
_IrrSetNodePosition( $CameraNode, 200, 100, 0 )
_IrrSetNodeRotation( $CameraNode, 0, -90, 0 )
_IrrSetAmbientLight(1, 1, 1)
_IrrHideMouse()
While _IrrRunning() And Sleep(10)
_IrrBeginScene(0, 0, 0)
_IrrDrawScene()
_IrrEndScene()
WEnd
_IrrStop()
[/autoit]Nutze den ISceneNodeAnimatorCollisionResponse.
In C++:
scene::ISceneNodeAnimatorCollisionResponse* collider =
sm->createCollisionResponseAnimator(
metaSelector, camera, core::vector3df(25,50,25),
core::vector3df(0, -10.f,0),
core::vector3df(0,45,0), 0.005f);
camera->addAnimator(collider);
collider->drop();
sm ist dabei der SceneManager, camera das CameraSceneNode, metaSelector der Triangleselector der meshes.
Ja, aber zählt DllCallAddress als normaler DllCall?
Ist denn inline-assembler erlaubt?
Heightmaps geben die Höhe an. Weiß=hoch, Schwarz=niedrig. Du müsstest also eine erstellen, die am Himalaya weiß ist und in den Meeren komplett schwarz.
Ich denke, es wird frei verfügbare (Creative Commons) irgendwo im Internet geben. Die haben dann natürlich nicht so gute Auflösungen.
Also "normale" Bumpmaps sehen ja in etwa so aus:
[Blockierte Grafik: http://media.giantbomb.com/uploads/0/5215/246594-normalmap01_large.jpg]
Nein. Das sind normalmaps, wo über die drei Farbwerte die Normale definiert wird. Bumpmapping ist der Überbegriff für die Methode. Normalmapping ist die meist angewendete Form des ganzen. Irrlicht kann mit einer Funktion aus der Heightmap die normalen berechnen. Die Werte als Graustufen zu übergeben ist also deutlich einfacher.
Sieht gut aus.
Alerdings hast du als Bumpmap noch einfache Graustufenbilder der Textur verwendet. Das ergibt natürlich keine so schönen Erebnisse.
1. Du solltest schon ein Thema vorgeben.
2. Das Resultat zählt und nicht die Anzahl an Zeilen/Zeichen. Programmierstil kann natürlich auch bewertet werden.
3. Zum Programmieren gehört auch eine vernünftige und Standartkonforme Darstellung des Codes.