bencikpeter / battleships

MIT License
0 stars 0 forks source link

SDL #3

Open Moroxus opened 8 years ago

Moroxus commented 8 years ago

Okej, takže ako rozbehat SDL

Linux:

SDL

sudo apt-get install libsdl2-dev

SDL_net

download  SDL2_net-2.0.1.zip from https://www.libsdl.org/projects/SDL_net/

unzip the folder.

Open up the terminal as root user.

navigate to the inside of the SDL2-2.0.1 folder

type:
./configure

wait for the configure to finish.

type:
make

wait for the make to finish

type:
make install

After the install is done SDL2 should be installed on your computer.
OR
Read the INSTALL.txt file after downloading SDL 2.0.

MacOS X

SDL

install SDL tutorial

SDL_net

install SDL_net tutorial

PS: na Macu som to netestoval, takže nezaručujem, že to funguje :D . Na Linuxe to fičí.

Moroxus commented 8 years ago

Pridal som SDL a SDL_net do projektu a je to skompilovateľné, ale hodil som to zatiaľ len do novej vetvy GraphicsUserInterface. Keď tak to môžeme mergnúť do master.

bencikpeter commented 8 years ago

sdl_net som rozbehal, ale uvedomuješ si že to je C-čko? Aby ma s tým neposlali kade ľahšie

Moroxus commented 8 years ago

Okej, tkaže SDL_net nepoužijeme.

Ďalšia vec. Rozmýšľal som ako efektívne vyriešiť, aby môj main loop nevyťažoval cpu na 100 % a zároveň bolo gui responzívne a zároveň som spracovával dokončené funkcie od business logic.

Môj main loop v podmienke volá funkciu SDL_WaitEvent, ktorá z fronty eventov vyberie event, a spracuje ho. Toto volanie funguje blokujúco, a teda efektívne, pokiaľ užívateľ nič nerobí a fronta eventov je prázdna, tak funkcia čaká. Reálne je threadu odobratý procesor a dostane ho až vtedy. Keď je sa vo fronte procesov objaví nejaký event ( užívateľ pohol myšou, stlačil tlačidlo atď ). CPU usage je minimálne a naša apka funguje efektívne. Háčik je v tom, že pokiaľ užívateľ vôbec neinteraguje s naším programom, a náhodou skončí asynchrónne volanie nejakej funkcie z business logic, ja to nemám ako skontrolovať, keďže stále funkcia SDL_WaitEvent blokujúco čaká na nejaký event, aby sa objavil vo fronte.

Najideálnejšie riešenie je SDL_PushEvent, čo efektívne vloží do fronty nejaký event. Teda každá funkcia, ktorú budem volať asynchrónne, by mala na konci vložiť event do tejto fronty. SD_PushEvent je thread safe, takže všetko by malo byť ok. Ako toto realizovať ?

Menší problém je, že SDL_PushEvent nesmie byť zavolaný skôr, ako return. Ak by bolo SDL_PushEvent zavolané tesne pred returnom, tak sa môže stať, že main thread začne spracovávať tento event skôr ako prebehne return a ešte nebude mať k dispozícii data z asynchrónneho volania.

Tento problém by sa dal riešiť deštruktorom nejakého objektu. Ak by sme mali triedu, ktorá nebude mať žiadne data a bude mať explicitný konštruktor a deštruktor, tak v konštruktore by sa mohol vytvoriť event a v deštruktore by sa zavolalo SDL_PushEvent. Na začiatku funkcie by sa vytvoril objekt tejto triedy na stacku a to by bolo všetko. Reálne keď bude končiť funkcia, tak sa zavolá return a až potom sa volá deštruktor, čiže až potom sa zavolá aj SDL_PushEvent.

bencikpeter commented 8 years ago

Navrhujem aby ten objekt brali funkcie ako parameter hodnotou Aby sa Lukáš mohol rozhodnúť čo tam dá... Keby prípadne mohol používať viac front a podobne. A asi tomu SDL bude rozumieť viac ako Juraj a bude lepšie vedieť čo tam cpať. A Juraj ten parameter nebude vôbec používať => zavolá sa deštrukor a to bude všetko

Moroxus commented 8 years ago

To by bol pekný nápad, ale takto to fungovať nebude. Pretože ak to bude tá funkcia brať hodnotou, tak sa vytvorí kópia. Ale originál mne ostane v maine a po skončení bloku ( nie najviac vnokajšieho bloku, ktorý ukončuje main ) sa zavolá deštruktor aj na ten môj originál a dostanem do fronty event, ktorý tam nemá čo robiť.

jurajvandor commented 8 years ago

Myslim ze to by nemal byt ziadny problem len mi musis povedat co mam dat do toho SDL_Event pripadne napis tu triedu aby sa ti to nebilo s nejakymi inymi eventmi. A jedine co ja spravim je ze ju na konci vytvorim s tym eventom a po returne sa sama znici a prida do tej tvojej fronty.

peto: ked tam da ten parameter hodnotou zavola sa potom ten destruktor aj u neho a prida mu to 2 krat do fronty

Potom sa este musime dohodnut co chces aby si BL pamatala. Ci si ma pamatat aj preibeh hry (kam sa strielalo) alebo len rozlozenie a ak hej tak akou hodnotou to budem znacit do toho 2D pola, a aky header ti vyhovuje na insertShip ten co tam je kde das jeden bod, ci je vertikalne/horizontalne a dlzku alebo dva body na konci lode

//EDIT: bol si rychlejsi :D

Moroxus commented 8 years ago

Hej, aby sa mi to nebilo s dalšími eventami už viem ako spravím. Len si to ešte trochu premyslím ako presne spraviť to API na to, aby sa s tým pracovalo čo najlepšie a dám tii vedieť.

Čo sa týka tej business logic, tak zatiaľ by som to nechal tak, že si pamätá len aktuálny layout. Keď tak to rozšírime potom ( alebo možno aj nerozšírime vôbec :D ) . Ten header čo tam je teraz je v pohode, len ty si budeš musieť ošetriť nejaké veci ako valid ship a invalid ship. Pokiaľ užívateľ zadá x = 9 a y = 9 a dĺžku loďe 3, tak to moc fungovať asi nebude. Vtedy by to chcelo vrátiť niečo invalid alebo čo a ja musím dať užívateľovi vedieť, že zadal invalid ship. Možno by bolo dobre použiť nejaký wrapper, kde bude zabalená tá loď a ešte nejaky bool, či je valid alebo nie. To môžeš vrátiť a ja si skontrolujem, či je tá loď korekt a podľa toho ju vykreslím alebo užívateľovi vynadám.

jurajvandor commented 8 years ago

Tak ono staci si myslim return bool hodnota lebo ty to budes volat synchronne toto nebude nijak komunikovat so sietou to len skontroluje ulozi a vrati true/false. Potom az na konci ked tam das getEnemyLayout a sendMyLayout sa to posle cez siet. A jasne osetrenie ci sa zmesti a ci je spravne umiestnena tam bude

bencikpeter commented 8 years ago

Na nevalidné vstupy sú podľa mňa celkom vhodným mechanizmom výnimky ;)

Moroxus commented 8 years ago

No to by som netvrdil. Výnimky by mali ošetrovať iba fakt situácie, ktoré za normálnych okolností nemôžu nastať. Užívateľ môže nastavovať nezmysly stále a výnimky v takom prípade môžu dramaticky ovplyvniť výkon. Výnimky by fakt nemali byť používané na control flow programu

bencikpeter commented 8 years ago

To nieje control flow. Podľa mňa výnimky typu InvallidArgumentExction sú určené práve na takéto situácie. Zmysluplné to podľa mňa je tak, že ty by si to mal checkovať ešte predtým ako to predáš BL vrstve a ten tvoj check by naozaj nemal hádzať výnimky.. Ale BL by si to mala ocheckovať aj sama a to už by sa ti malo vrátiť z výnimkou

Moroxus commented 8 years ago

No ja uvidím, či to vôbec ja budem čekovať.

jurajvandor commented 8 years ago

ja si myslim ze je to uplne zbytocne ved ja si to musim ajtak checknut a bud ti vratim true/false alebo nejaky enum

bencikpeter commented 8 years ago

Neviem či by sa toto nepovažovalo za bezpečnostnú dieru

Dňa piatok, 29. apríla 2016 jurajvandor notifications@github.com napísal(a):

ja si myslim ze je to uplne zbytocne ved ja si to musim ajtak checknut a bud ti vratim true/false alebo nejaky enum

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/bencikpeter/battleships/issues/3#issuecomment-215867281

Peter Benčík ml. Kontakt a info tu. http://about.me/bencik.peter