Kirjautuminen
Haku
Pikalinkit
Avoin ohjelmointikurssi
1. Vaihda tuo klik teksti tosta, kuten lebe80 sanoi.
2. Tuo vilkkuva teksti on mielestäni ärsyttävä, eikä varmastikkaan ainakaan houkuttele kävijöitä olemaan sivulla pitempään.
Ps. Nämä ovat mun mielipiteitä.
dartvaneri kirjoitti:
1. Vaihda tuo klik teksti tosta, kuten lebe80 sanoi.
2. Tuo vilkkuva teksti on mielestäni ärsyttävä, eikä varmastikkaan ainakaan houkuttele kävijöitä olemaan sivulla pitempään.Ps. Nämä ovat mun mielipiteitä.
Älä suotta ole vaatimaton. Faktoja nuo ovat.
Klik ja vilkkuva teksti,
Tässä huomaa taas näitä ikäpolvien eroja, nuo molemmat ominaisuudet sekä vilkkuva teksti että sana klik edustavat minulle kehitystä, minä kun olen yhä siirtämässä näitä 1988 - 1992 suunnittelemiani pelejäni nettiin javalla, niin, kun noita ekoja suunnitelmia tuolloin menneessä rakentelin modeemin kanssa, niin, nuo molemmat asiat olivat kehitystä, taitaa olla aika jo ajanut ohitse molemmista, heh.
Mitä animaatiota suositta, laitanko sitten pieniä kuvasnappeja jqueryllä, snappeja jotka vaihtuvat faden taikka liukumisen kanssa ruudulla.
---
Kun muistaakseni halusit myös sitä vanhempaa väkeä pelaamaan niin kannattaisi jättää tuollaiset suomi-englanti sekoitukset pois kuten tuossa sinun "klik" korvaajassasi ("Pelaa lautapelejä tästä buttonista !!") on. Lisäksi se on muutenkin huono tapa.
Animaatioista,
Unohda ne.
Et selkeästikään ole graafikko, niin pidä pelit ilman ylimääräisiä graafisia kikkailuja.
Graafikko,
Minkälaista grafiikkaa sinä toivoisit sivulla olevan jotta minua voisi pitää edes tavallisena koti graafikkona ?
Ei nämä minun grafiikkani nyt minusta ihan niin kovin huonoja ole, muistaa toki sopii että käytössä ei ole esim. corelin kaltaista kehittynyttä ohjelmistoa, vain gimp ja inkscape ja myöhemmin käytän vielä blenderiä.
Tuohon animaatioon, laitan vain hieman animaatiota kaikkeen toimintaan mitä sivustolle sitten uploadaankaan.
---
Graafikko,
Ensinnäkin, grafiikkasi ei ole äärimmäisen huonoa, enkä ole näin sanonutkaan. Graafinen jälki vain ei ole "coders arttia" kummoisempaa.
Toiseksi, nykyaikaiset softat eivät rajoita graafista ulosantia.
Kolmanneksi, keskity niiden pelien tekemiseen, äläkä grafiikan viilaamiseen. Tuntuu, että käytät kymmenen kertaisen ajan animaatioiden viilailuun, kun sinulla selkeästi on muitakin ongelmia peliesi teossa (aikaisemmin mainitut oudot aikarajoitukset yms.). Itse en näe ulkoasuissasi ja grafiikoissa mitään järisyttävää eroa, oli sitten hevosnappula vihainen tai sivuillasi teemana brazil.
Lopputoteama,
Älä käytä tässä vaiheessa aikaasi animaatioiden ja graafisen ulkoasun fiilaamiseen. Lopuksi, kun pelit ovat ulkoasua vaille valmiit, niin vaikkapa googlaa vaikkapa kuvapankeista ammattilaisten tekemiä ulkoasuja ja grafiikoita ja hanki ne sieltä muutaman euron hintaan.
ps.
Kukaan ei käytä vuonna 2012 Corelia.
Hei taas,
Olen ottanut tähän työ rupeamaan näitä pelejäni taas kerran, tässä kuvankaappauksia ->
http://temp4322.dy.fi/images/snap001.png
http://temp4322.dy.fi/images/snap002.png
http://temp4322.dy.fi/images/snap003.png
http://temp4322.dy.fi/images/snap004.png
Miettisin että voisin jo asentaa tämän avaruus pilotit 2312 demon sivulle, ihan kesken vielä mutta ryhdyn säätelemään nyt lähipäivistä lähtein.
Avaruus pilotit 2312 -
Pelissä on viisi tulevaisuus ajan avaruus alusta molemmalla nettaajalla.
Aseina on erillaisia avaruus aseita, peli testaaminen ratkaisee mitkä valitaan julkaisuun.
Alukset liikkuvat warpilla, eli ne jumppaavat nopeasti.
Alukset kääntyvät hieman hitaasti, jotenka niitä täytyy warpata tarkoin harkiten.
Idea on kerätä pisteitä taikka tuhota vastustajan alukset, peli testaaminen ratkaisee.
Piirtelen näitä alus ja ase graffoja ensi viikosta lähtein, kenties jo huomisesta perjantaista, katselee nyt mitenkä jaksan.
---
Öh,
Joo tämä on aika nolo tilanne, minulla on tämä minun kotiprojektini yhä kesken, mutta, olen vain kotiharrastaja, ja mietin tässä nyt että mitä kaikkea lakia tulee tietää, sain aikanaan luvan ensin soneralta, sitten suomicomilta ja nyt viimein ovh-hostingilta ylläpitää pientä java palvelua heidän servereillään, ja noilla lauseilla sitten olen eri open ja ilmais ohjelmilla mennyt eteenpäin.
Onko teidän tiedossanne mitään laki opusta jokin 'koti suomalaisen pelisuunnittelijan käsikirja', josta voisi lukea kaikkea kotiprojekteihin kuuluvaa lakia.
Minua kiinnostaa itse ylläpitoon ja erillaisiin copyrighteihin kuuluvat asiat.
Copyright puolelta kiinnostaa kovasti alle 20x20 pikseliä grafiikka, mikä riittää erottamaan mainitun koko luokan kuvat, täysin yksivärisistä vastaavista kuvista, joku aikoinaan kertoi että amerikassa tehtiin paljon pieni pikselistä peliä, hintaan $4.95, pelejä julkaistiin ja niitä tehtiin ihan varta vasten perustetuissa firmoissa, niitä ei oltu tarkoitettu myyntiin taikka menestykseen, niillä vain saatiin (C) oikeudet kaupalliseen peliin jossa on alle 32x32 pikseliä grafiikkaa, en täysin tiedä mistä tämän voi vahvistaa, joku vaan kertoi, ja en halua alkaa tapella tollaisten firmojen kanssa, eli, mikä riittää erottamaan kuvan vastaavasta yksivärisestä.
kuva esimerkki - http://temp4322.dy.fi/images/temp001.png
Minulla ei ole mahdollisuutta vahvistaa tuon kuvan minulle kuulumista, todella moni on varmaankin vastaavia piirtänyt myös suomessa, mutta onko ihan julkaisu juttua, tämä esimerkki kuva taitaa olla liian iso minun projektilleni, täytyy varmaankin rakentaa niin sanottua huonoa grafiikkaa, kenties jotain 40x40 pikseliä ja sitten epätasaisia virhekohtia kuvaan, mitä laki sanoo 'oikein' piirretyistä pikku kuvista, mikä riittää erottamaan minun kuvat toisten kuvista.
---
Sonera, eikä mikään muukaan palvelu estä sinua pitämästä sivuillasi tuollaista materiaalia. Viimeisen kahden kuukauden aikana jokaisessa viestissä olet ihmetellyt samaa asiaa: saanko pitää pelisivustoa? Vastaus on kyllä. Jos sivusto sisältää laitonta materiaalia, silloin se on arvatenkin lainvastainen.
Mitä kuviin tulee, jos ne kerran olet piirtänyt itse, niin silloin ne ovat sinun eikä kenelläkään muulla ole niihin oikeuksia - olettaen siis, ettet ole niitä antanut.
Ja en tajua, mitä eroa on 32x32 ja 40x40 pikseliukoilla tekijänoikeustaistossa...
edit:
ja viimeisen kerran. -----> Keskitä <----- aikasi nyt vain niiden ---> pelien tekemiseen <---, äläkä jaksa pohtia vielä mitään tekijänoikeuksista, varsinkin kun olet tehnyt itse kaikki graffat ja pelikoodisi.
kpzpt: Koska on tullut erittäin selväksi että osaat mekaanista koodausta mutta sinulle ei ole minkäänlaista ymmärrystä reaalimaailman asioista, suosittelen että hakeudut ohjelmoijaksi johonkin harrastelijaryhmään jossa tiimin vetäjä käskee mitä teet (koodaat) ja joku muu tekee grafiikat ja hoitaa pelin suunnittelun ideatasolla. Tiedän ihmisiä jotka ovat esimerkiksi matemaattisesti lahjakkaita ja se on hienoa, mutta heitä ei missään nimessä tulisi laittaa minkäänlaiseen luovaan työhön. Tässä on nyt samasta kysymys, ylität selvästi oman osaamisesi yrittämällä tehdä kaiken itse.
Tuplabufferi,
Vielä on tämä AsiakasOhjelman perus runko työn alla, on ollut kaikenlaista LWJGL AWT ja joskus ammoin myös JOGL versiota, nyt on taas tämä neljäs vaihtoehto rupeamassa voittajaksi tässä valinta arvuuttelussa mitä minä olen käynyt koko vuoden.
Kysymyksiä.
Jos laitan tuplabufferiksi yhden 1920x1200 pixeliä kokoisen bufferedimagen, niin mitä ongelmia tästä voi seurata.
1) Minä luovun bufferstrategy(2) käytöstä ja alan käyttämään bufferstrategy(1), jotenka on vain yksi bufferi käytössä.
2) Rakennan bufferedimagen 1920x1200 kooltaansa, ja alan käyttämään sitä tuplabufferina, omien drawimage drawline drawrect fillrect drawoval filloval drawpolygon fillpolygon käskyjen avulla.
3) Mitä käy jos tämä bufferedimage 1920x1200 menettää kiinnityksensä int[] jonoon, johonka se on ohjattu, kuinka toimia tilanteessa ja onko tilanne edes mahdollinen.
4) Otan kaikkea vinkkiä vastaan, kun rakennan oman transform, scale, käskytyksen, tuohon bufferedimageen 1920x1200.
Tämä AsiakasOhjelma on jo ihan ok kunnossa mutta mietin vakavasti että ottaisin huomioon myös nämä tulevaisuuden pelini, eli pelit joissa on esim. 4096x4096 peli kenttiä taikka jopa isompia, tällöin ei tämä perus awt oikein taitu toimeen, on liian raskasta grafiikkaa, eli tarvitsen tämän oman bufferedimagen jonka pixeleitä muuttelen.
Kiitos kun jelppaatte kommentein..
---
kpzpt,
tsemppiä projektiin..
Itseltä olis keskittymiskyky loppunut pari vuotta sitten
edit.
ja komppaan Rasengerin viimeisintä viestiä
Projektini,
Tuosta Rasengerin viestistä, niin, minä jälleen kerran muistuttaisin että olen vain tavallinen pulliainen kaupan/tehdas/varasto ( tällä hetkellä siirtymässä uuteen kauppaan ) alan työntekijä, vain puolikas lukukausi kauppaoppilaitosta ja täsmälleen puolet aikuislukiota käytynä, minulla ei ole keskusteltuna näitä laki asioita taikka kaikkea mitä täytyy tietää ohjelmoinnista, sain luvat palvelun tarjoajaltani.
Olen lähtenyt tähän projektiin javalla josta käytän vain oikeastaan NIO ja GRAPHICS2D luokkia.
Molemmat ovat yksinkertaisia ja helppoja oppia, mutta, oletta oikeassa kun informoitte, sillä esim. apache jota käytän tiedoston jakoon, ja vielä tämä Javakin, niin, niitten päivitysten seuraaminen tulee ajankohtaiseksi kunhan tästä toiminnan avaan, ja tämä on minusta aika lailla se vaikein asia, ylläpidossa ja toiminnan valvonnassa, kaikenmaailman päivityksiin reagoiminen, ja vielä niin että kenenkään laitteet eivät vaarannu, oli sitten kyse modeemista näytönohjaimesta taikka emolevystä, toivoisin jotakin apua, jos jotakin isompaa muutosta apacheen taikka javaan tulee, niin emailina käyttäjiltä.
Mutta, tämä on vain sotapeli kotiprojekti ja tarkoitettu aloittaessani 2009 vain sisarelleni serkuilleni ystävilleni ja heidän vastaaville, sitten vain laitoin projektini muittenkin katseltavaksi nettiin ja tässä nyt ollaan.
---
Tässä lautapelisivusto kotiprojektini tämän päivän rakennelmat - http://temp4322.dy.fi
---
lainaus:
Jos laitan tuplabufferiksi yhden 1920x1200 pixeliä kokoisen bufferedimagen, niin mitä ongelmia tästä voi seurata.
Tuo on aika valtavan iso tuplabufferi ainakin mun 1680x1050 näytölle. Selain ei ole kokonäytöllä ja peli on vielä sen framen sisällä pienempi. Sun kannattais vaan määrittää tuplapuskuri sen kokoiseks mitä pelaaja käyttää.
Kuten jo aiemmin sanottu, tuplapuskurin skaalaaminen on hidas ja huono ratkaisu.
lainaus:
Tämä AsiakasOhjelma on jo ihan ok kunnossa mutta mietin vakavasti että ottaisin huomioon myös nämä tulevaisuuden pelini, eli pelit joissa on esim. 4096x4096 peli kenttiä taikka jopa isompia, tällöin ei tämä perus awt oikein taitu toimeen, on liian raskasta grafiikkaa, eli tarvitsen tämän oman bufferedimagen jonka pixeleitä muuttelen.
Jep, noin isoja kuvia kannattaa välttää kuin ruttoa. Kannattaisi tutustua vektorigrafiikkaan, tai koostaa grafiikat vaikka useista pienistä kuvista. Tai jos toisin ilmasen, jos haluan piirtää tiilimuurin niin en tarvitse yhtä valtavaa kuvaa muurista. Riittää kun minulla on 1 kuva tiilestä jota toistaa, ja piirtää laastit väliin.
User137:n mainitsemalla tile based -tekniikalla pääsee tosiaan pitkälle vaikka kuinka isojen karttojen kanssa (tekniikkaa käytetty tosiaan jo ihan pelien alkuajoista lähtien, näkyvimmät esim. Nintendon 1980-luvun peleissä, mutta myös sekaisin muiden eri tekniikoiden kanssa). Tekniikkaa pystyy käyttämään jopa 3d-peleissä. Nykyprosessoritehojen ansiosta voidaan välttyä monista ongelmista, jotka jouduttiin ratkomaan esim. graafikon toimesta vielä 90-luvun alussa. Nykyäänhän eri graffoja on suhteellisen nopea "blendata" toiseksi, esim. hiekkaranta muuntuu vihreäksi ruohikoksi.
Tässä vielä erinomainen esimerkki, mihin parhaillaan kyseisellä tekniikalla pääsee, jos tekijällä riittää vain osaamista:
http://lostgarden.com/uploaded_images/
edit:
Itseä kyllä ihmetyttää paljolti asioiden "tietämättömyytesi", jos olet pelejä tehnyt jo viime vuosituhannen puolella. Itsellä ei tosiaan ole Java-kokemusta minkäänmoista, mutta pääpiirteittän kyllä osaisin hahmottaa asioita, miten lähtisin niitä ratkomaan. Itsellä tosiaan ikää vasta 32 vuotta, ja pelejä tehnyt 80-luvun lopulta harrastusmuodossa.
Lähinnä mietityttää, että pelaatko itse yhtään mitään pelejä, selailetko nettiä yms. kun moni asia tuntuu menevän sinulla ns. persedellä puuhun. Eli asutko kenties jossain tynnyrissä?
Muutamien ulkomaisen foorumin perusteella tunnut ihmettelevän usein samoja asioita siellä, mitä täälläkin, vaikka saat niihin joka kerta yksiselitteisen ja selvän vastauksen (esim. tuo aikaisemmin käyty kehotus huolehtimatta jättäminen pelaajien konelämpöjen mahdollisesta nousemisesta).
editedit:
Eikä ollut tarkoitettu dissaamiseksi, vaan ihan "ammattimaiseksi" ihmettelyksi.
Ihmettelyä,
Minulla on muutama ongelma kohta lukittunut tässä projektin etenemisessä.
Ensimmäinen on tämä tuplabufferi jota käyttää, minulla on tällä hetkellä bufferstrategy(2) käytössä, mutta se ei taida soveltua ihan jokaiseen peliini, sen käyttö on omiaan sitten näissä arkade laudoissa.
Toinen on tämä että jos tulee käyttäjiä jotka käyttävät ohjelmaani alle minimi vaatimusten mukaisella laitteella, en kuitenkaan tahtoisi rakentaa ohjelmaa joka polttaa käyttäjän koneen joka kerta kun on alle minimi vaatimusten mukainen kone, tämä ongelma johtuu siintä että en voi laittaa sleep arvoa näytönohjaimelle, CPU on turvattu rajoittimella, pelien aikana minimi sleep on 750 ms, ja se lie riittävää, mutta GPU on iso ongelma enkä oikein tiedä mitä tehdä asian kanssa, liekö sitten vain täytyy pudottaa pois kehityksestä nämä arkade pelit ja laittaa staattiset laudat joissa ei juurikaan mikään muutu ruudulla, elikä suomeksi sanottuna vähän niinkuin muillakin, tämä on kuitenkin aloitettu sukulaisille ystäville suunnattuna projektina koko sivusto.
---
Tuo tuplabufferi jota mainitsin 1920x1200, niin tätä tuplabufferia ei tietenkään koskaan skaalata vaan se piirretään ruudulle drawImage ( 0,0 ) kohtaan jolloinka siintä näkyy vain se osa mikä ruudulle mahtuu, minulla on erikseen oma setviewport() käsky jolla rajaan kaiken toiminnan appletin pikseli koon mukaiselle alueella tuossa 1920x1200 tuplabufferissa, lisänä voin määrätä tällä 1920x1200 tuplabufferille tuon setviewport() käskyni avulla käyttöön vaikka vain 320x240 kokoisen alueen, ja sitten kun ruudulle piirretään tätä 320x240 aluetta niin tämä pieni kuva sitten skaalataan ruudulle.
Ei minulla enää ole ihan peli suunnittelu aloittelija ongelmia, kyllä nämä ovat Javan vajavuuksista johtuvia, eteenkin näytönohjaimen käytössä olevista vajavaisuuksista.
En oikein pääse eteenpäin näitten arkade pelien kanssa kun ajattelen että joku käyttäisi ohjelmaani, ei niinkään aivan liian hitaalla GPU:lla vaan vain hieman liian hitaalla, jolloinka GPU rasite olisi arkade peleissä yli 50%-80% kenties vielä enemmän, aivan liian hitaat näytönohjaimet ovat tietenkin myös ongelma mutta tällöin näkee ruudulla nykimistä ja muuta pätkimistä, olen ihmeissäni näistä korteista kuten NVIDIA GF4200 ja NVIDIA GF5200 ja jos näitä ajetaan isolla näytöllä, niin, voin joutua selittely tilanteeseen.
Liekö sittenkin parhain ratkaisu pudottaa frameratet maksimi 1-2 fps ja kaikki animaatiot ja arkade pelit pois suunnitelmista, ja kenties käyttää active rendering sijaan JPanelia ja repaint () käskyä.
---
Minulla on tile grafiikka käytössä ensimmäisen kerran tässä heidän kunniansa päivät pelissä, olen miettinyt että laittaisin myös editorin jolla pelaajat voivat tehdä omia peli skenaarioita. HKP sisältäisi 40x40 alueen jollekka voi laittaa maastolaattoja ja eri graafisia koristeita, eli laittanen tämän pelin valmistuksessa käyttämäni editorin myös muitten käyttöön.
---
Kuten sanottua, ei nykyään tuon tasosissa peleissä tarvitse juurikaan murehtia näytönohjaimista ja prossuista. Todella harvalla on niin alkeellinen kone, etteikö pyörittäisi niitä pelejäsi. Ja niiden jotka omistavat niin antiikki kone, ei tarvitse sitten pelata. Eihä BF:stäkään ole tehty versiota, joka pyörisi antiikki koneilla.
FullHD,
Tämä että minulla on tämä FullHD tuki on aika iso ongelma, tuki johtuu siintä että tämä todella oli alkuun sukulais käyttöön suunnattu sivusto.
Saatan joutua selittely tilanteeseen asian takia, "miksi juuri sinä tarjoat suomen netissä FullHD tukea, kun isommat alalla olevat eivät ?"
Tämä sivusto oli tarkoitettu sukulais ystävä käyttöön vain kun aloitin, vaikka kaikilla uusilla käyttäjillä onkin hienoja ja hyviä koneita, niin, ihmettelen tässä vielä vähän aikaa, tietojeni mukaan nämä minimi vaatimukset kuitenkin riittävät mitkä minulla on alimmaiseksi rajattuna, mutta minulla ei ole varmuutta minimi vaatimukset alittaviin koneisiin, ja tämä johtuu siintä että en voi sleepata GPU:ta, esim. rajoittaen sen johonkin < 33 %, kuten olen CPU:n rajoittanut peleissä < 25 %.
kpzpt kirjoitti:
Ihmettelyä
Täytyy sanoa, että minäki kyllä suuresti ihmettelen tätä touhua.
kpzpt kirjoitti:
en kuitenkaan tahtoisi rakentaa ohjelmaa joka polttaa käyttäjän koneen joka kerta kun on alle minimi vaatimusten mukainen kone
Tarjosin muistaakseni sata euroa, jos onnistut polttaan mun koneen. Et oo vielä onnistunu. Etkä onnistu, niin voin hyvillä mielin vaikka tuplata tarjouksen.
kpzpt kirjoitti:
tämä ongelma johtuu siintä että en voi laittaa sleep arvoa näytönohjaimelle, CPU on turvattu rajoittimella, pelien aikana minimi sleep on 750 ms
Et tarvitse nukkua näytönohjaimella. Et tarvitse nukuttaa prosessoriydintä 75% ajasta. Uskoisit nyt kerranki ku sanotaan.
kpzpt kirjoitti:
En oikein pääse eteenpäin näitten arkade pelien kanssa kun ajattelen että joku käyttäisi ohjelmaani, ei niinkään aivan liian hitaalla GPU:lla vaan vain hieman liian hitaalla, jolloinka GPU rasite olisi arkade peleissä yli 50%-80% kenties vielä enemmän
Ajatko muuten autollaki aina vaan neljääkymppiä, ettei moottorin kierrokset nouse vahingossakaan yli tuhannen?
kpzpt kirjoitti:
Liekö sittenkin parhain ratkaisu pudottaa frameratet maksimi 1-2 fps
No ei ainakaan pelaajan kannalta. Tommosta tökkimistä nyt kato vanha Erkkikään.
kpzpt kirjoitti:
Toinen on tämä että jos tulee käyttäjiä jotka käyttävät ohjelmaani alle minimi vaatimusten mukaisella laitteella, en kuitenkaan tahtoisi rakentaa ohjelmaa joka polttaa käyttäjän koneen joka kerta kun on alle minimi vaatimusten mukainen kone, tämä ongelma johtuu siintä että en voi laittaa sleep arvoa näytönohjaimelle, CPU on turvattu rajoittimella, pelien aikana minimi sleep on 750 ms, ja se lie riittävää, mutta GPU on iso ongelma enkä oikein tiedä mitä tehdä asian kanssa, liekö sitten vain täytyy pudottaa pois kehityksestä nämä arkade pelit ja laittaa staattiset laudat joissa ei juurikaan mikään muutu ruudulla, elikä suomeksi sanottuna vähän niinkuin muillakin, tämä on kuitenkin aloitettu sukulaisille ystäville suunnattuna projektina koko sivusto.
Miksi et voi uskoa kun sinua kokeneet ohjelmoijat opastavat? Et saa kenenkaan konetta palamaan Java-appletillasi, vaikka yrittaisit. Jos jonkun kone palaa (aarimmaisen epatodennakoista etta se tapahtuisi nimenomaan sinun peliesi aikana), syy on liiassa polyssa, huonossa jaahdytyksessa, tai jossain aivan muussa -- se ei ole sinun ongelma, etka voi asialle tehda mitaan vaikka kuinka paljon ohjeistaisit prosessia nukkumaan. Unohda jo se sleeppien kanssa pelleily ja anna sovelluksen kayttaa aikaa juuri niin paljon kuin se freimin piirtamiseen tarvitsee.
lainaus:
En oikein pääse eteenpäin näitten arkade pelien kanssa kun ajattelen että joku käyttäisi ohjelmaani, ei niinkään aivan liian hitaalla GPU:lla vaan vain hieman liian hitaalla, jolloinka GPU rasite olisi arkade peleissä yli 50%-80% kenties vielä enemmän, aivan liian hitaat näytönohjaimet ovat tietenkin myös ongelma mutta tällöin näkee ruudulla nykimistä ja muuta pätkimistä, olen ihmeissäni näistä korteista kuten NVIDIA GF4200 ja NVIDIA GF5200 ja jos näitä ajetaan isolla näytöllä, niin, voin joutua selittely tilanteeseen.
Paskapuhetta. Voit joutua selittelytilanteeseen jos kirjoitat viruksen tai muun haittaohjelman.
lainaus:
Liekö sittenkin parhain ratkaisu pudottaa frameratet maksimi 1-2 fps
Pelleilya, jolla saat pelikokemuksen taysin ja turhaan pilattua.
Oikeasti, kuten tuolla eräällä enkkufoorumilla sinulle jo sanottiin viime vuonna, teet käyttäjälle vain palveluksen, jos saat jonkun vanhan koneen hajotettua.
Lopettakaas nyt jo tuo paskan puhuminen koneen hajoamisesta noiden turhien räpellysten takia. Se on täysin mahdoton skenaario eikä sillä pidä alkaa sekoittaa rukan päätä, kun näköjään mikään muukaan asia ei päähän mahdu. Jos joku haluaa tuhlata vuosia elämästään siihen, että tekee tarkoituksella peleistään täysin pelauskelvotonta moskaa, niin ei me näköjään sille voida mitään.
Joudut muutenkin selittelemään meille jo nyt lähes päivittäin noita hulluja valintojasi, joten turhaan kannat huolta siitä, että joku GF 5200:n käyttäjä saattaisi tulla kyselemään sinulta resoluutiovalinnoistasi.
Tämmöinen huomio vain yhtä turhautuneena sivustaseuraajana.
Resoluutiot ja GPU tehot,
Ok, lopetan aiheesta puhumisen tähän, jatkan javaan luottaen, ja katselen tässä ensi viikolla taikka sitten jo tänä viikonloppuna, josko liittäisin tuon caveflyer tyylisen tuplabufferin tähän AsiakasOhjelmaan bufferstrategy(2):n lisäksi.
Nuo isommat sotalaudat rakennan tällä caveflyer tavalla, tällöin kaikki kuvat ovat perusmuistissa int[] jonoissa ja kuvat sitten piirretään tuplabufferin muistiin, niihin int[] jonoihin mitä sitten tuplabufferista onkaan grabattuna.
Kiitosta nyt kuitenkin keskustelusta..
Erikoista alunalkaen on tuo "bufferstrategy". Miksi se on tarpeen? Eikö perinteiset piirtotekniikat riitä tuplapuskurointiin ja muuhun? Ei ainakaan pikselitasolla kannata alkaa määrittelemään omia rutiineja, varsinkin kun puhut int[] jonoista. Kuulostaa huolestuttavalta.
User137 kirjoitti:
Erikoista alunalkaen on tuo "bufferstrategy". Miksi se on tarpeen?
Koska se on juurikin Javan "perinteinen piirtotekniikka" kaksoispuskuroinnin suhteen.
Taas oppii jotain uutta tässä ketjussa ;) Kuulosti ihan joltain omalta viritykseltä joka kävis koko ruudun int taulukkona läpi. En käytä Javaa ja hyvä niin.
Itseäni häiritsee nuo yhdyssanavirheet kuten "kotiprojekti sivusta" kuuluisi olla "kotiprojektitsivusta" ja "harjoitus sivu" kuuluisi olla "harjoistussivu". Muuten hineno näköinen sivusto.
Heikkoa läppää, Reino.
Hyvä, että reino huomasi. Monelta nuo kyseiset kirjoitusvirheet olivat varmaankin jääneet huomaamatta.
Tietoturvallisuus,
Öh, tässä taas säätelyjä, tällä kertaa salasana ja käyttäjätunnukset ja itse apache.
1)
Minulla on mietteissä että laittaisin 1024 kappaletta 1024 merkkiä pitkiä yliveto satunnais byte[] jonoja kaikkien salasana käyttäjätunnus ja pelitallenne ja pelifilmi tietojen päälle, useita kertoja, nämä byte[1024] satunnais jonot uploadaisin omasta kotikoneestani palvelin ohjelmaani, aina kun palvelin ohjelma käynnistyy.
Tämä on minun ensimmäinen testini hieman .txt tallennetta turvallisemmasta käyttäjä ja salasana tallentamisesta, jotenka mitä minun olisi hyvä tietää käyttäjätunnus tallentamisesta.
2)
Apache, minulla ei ole ihan täyttä luottoa apacheen, mietin tätä Java servelettiä asiaan, mutta en tunne servelettejä ihan tarkkaan, jos laitan java serveletin kuuntelemaan porttia 80, niin kuinka monimutkaista on palauttaa sillä tietoa, eli .html .png .jpg fileitä, onko ihan muutaman Java rivin juttu, vai vaatiiko monimutkaistakin tiedonkäsittelyä, ymmärtääkseni http palaute on aika helppo, mutta entä kuvat.
Lisäys.
Mietin tässä täysin suljettua palvelinta käyttööni, eli vain java servelet porttiin 80 ja itse 43000 peli siirroille, foorumi tuohon asiakasohjelmaan, ja kaikki muukin tärkeä, eli vain 80 ja 43000 palvelimesta auki ja molemmissa ihan oma ohjelma joka on niin suppea että ei muodosta tietoturva aukkoja.
Nämä ovat aloittelijan ihmettelyjä tässä ;)
Mitäs jos vaikka tekisit salasanasuojauksen ihan kuin kaikki muutkin, eli lasket salasanan tarkistesumman, ja suolaat sen jollain suolalla.
Eli käytä vaikkapa sha1() -tarkistesummaa. Muutenkin kannattaa varmaan ihme vimpaimiesi sijaan tutkia miten muut tuon tekee. Eli vaikka pelitieto onkin silmin luettavissa jossain, niin palvelin pää taas vaatisi oikeain tarkistesumman, ennen kuin se hyväksyy lähetetyt tiedot, mihin ihmeeseen nyt niitä aiotkaan käyttää.
"En luota maailman käytetyimpään palvelinohjelmistoon, joten ajattelin koodata oma huonon viritelmäni tilalle, vaikken ymmärrä mitään tietoturvasta enkä ohjelmoinnista, enkä missään nimessä kuuntele ketään, joka sanoo minun tekevän asiat väärin."
Onnea.
P.S. Nyt kun päivänselvää, että koko käyttäjärekisteri tulee em. ehtojen täyttyessä vuotamaan nettiin, niin en missään nimessä käyttäisi SHA1-tiivistettä. Ainakaan generoimatta jokaiselle käyttäjälle omaa suolaansa. Silloinkin "varmistetaan" vain se, että vain osa salasanoista murretaan ensimmäisen viikon aikana.
P.P.S. Salasanojen tallentaminen tekstitiedostoon on ihan yhtä turvallista tai turvatonta kuin tallentaa ne MySQL-tietokantaan tai kotitekoiseen java-applettiin. Ainoat merkitsevät asiat on 1. salasanojen käsittely tiivistefunktiolla ja 2. estää julkinen pääsy tietokantaan.
Josset edes tiedä, miksi jotain pitää tehdä, niin älä aloitakaan. Silloin pitää alkaa ottaa selvää siitä, että varoittaako vaisto oikeasta vaarasta vai meneekö hihhuloinnin puolelle.
Toisaalta, tekstitiedosto on helpompi jättää tallentamatta palvelimelle sellaiseen paikkaan, josta sen voi selaimella avata suoraan, kun taas tietokantaan pitää saada syötettyä se kysely, joka tulostaa esim. kaikki rivit.
Suolaaminen,
Voinko saada hieman tietoa suolaamisesta, onko se php termi ?
Minä koen että on parempi käyttää omaa salausta kuin näitä tunnettuja jo kaikkien murrettavissa olevia, otan muutamia maisema kuvia, ja piirtelen niitä päällekkäin gimpin kanssa .5f läpinäkyvyydellä ja sitten vielä .5f läpinäkyvyydellä jokin noise toiminta ja syntyvästä kuvasta sitten otan näitä 256 byteä - 1024 byteä pitkiä rimpsuja joita satunnaisesti piirrän tallenteitten päälle, tämä on vähän ongelma jos suoritettavana olevan java koodin muuttujia saa kaivettua esiin, eli nämä muuttujina olevat byte[] rimpsutkin pitäisi sitten vielä salata koodin kanssa, mutta jos taas java koodinkin saa näkyviin, täytyy jotakin kivaa edes takaisin sörsseliä järjestää käyttäjätunnusten ja tallenne tietojen päälle, mutta, ilmeisesti ihan toimivaa salausta ei pysty javalla rakentamaan.
Pyytäisin myös lisäksi taas hieman kohteliaampaa EU sävyä, tämä on silti minun kotiprojektini ketju.
---
Muuten vaan, onko mahdollista tehdä tietokantaan asetus juuri esim salasanojen hasheille, että voi kysyä korkeintaan yhden kerrallaan? Pitääkö tällaiselle tehdä oma "parseri" tvs. välipalvelin, jonka kautta kyselyt lähetetään. Siinä tapauksessa tosin paluuviestitkin pitäisi välittää tuon kautta, tai kräkkeri ottaisi suoran yhteyden tietokantaan. Olettaen että tietää adminin tunnukset. Olisi tietty hidas ratkaisu. Ja onhan se jo ongelma sinänsä että joku pääsee hasheja ylipäätään kyselemään...
kpzpt kirjoitti:
Voinko saada hieman tietoa suolaamisesta, onko se php termi ?
Ei ole, ihan yleinen kryptografiatermi.
kpzpt kirjoitti:
Minä koen että on parempi käyttää omaa salausta kuin näitä tunnettuja jo kaikkien murrettavissa olevia
Tuota lähestymistapaa kutsutaan '"security" through obscurity' -termillä, eli näennäistä turvallisuutta epämääräisyydellä. Käytännössä siis korvaat vaikeasti murrettvan, tietyissä erityistilanteissa hieman helpommin mutta silti vaikeasti murrettavan menetelmän omalla, luultavasti äärimmäisen helposti murrettavalla menetelmällä.
Toki monet näennäissuojatkin on melko toimivia niin kauan kuin niitä ei käytetä yleisesti.
Salaaminen Javassa,
Liekö Java Databasen käyttäminen ainoa oikea tallenne tavoista, entä kuinka salata Java databasea niin että salaus on toimivinta.
Lienet ihan oikeassa siinä, että Javalla ei voi rakentaa murtamatonta suojausta. Sellaista ei ole olemassa.
Kryptografiassa siirryttiin 1970-luvun lopulla RSA:n keksimisen myötä uuteen aikaan, jossa saadaan kaikkien tuntemalla algoritmilla paljon algoritmien epätoivoista piilotusta parempia tuloksia, sillä vaikka kaikki algoritmit voidaan murtaa, modernien algoritmien tapauksessa nopein keino on salausavaimen arvaaminen.
Modernien salausmenetelmien tapauksessa murtamiseen nopeimmillakin tietokonekomplekseilla menisi aikaa suunnilleen universumin iän verran, tarvittaessa paljon kauemmin. Omat kyhäelmät sen sijaan murtuvat hetkessä, ainakin verrattuna moderneihin yleisesti tunnettuihin menetelmiin. Eiköhän se universumin elinikä nyt tällä kertaa riittäisi?
Oman algoritmin keksiminen on typerä idea. Jopa monissa ammattimatemaatikoiden kehittämissä salausalgoritmeissa on kämmejä, jotka tekevät niiden murtamisesta helpompaa. Miten sitten omassa kyhäelmässäsi? Miten on, riittääkö pokka haastamaan tuhannet ammattimatemaatikot ja professorit vuosikymmenten kokemuksella lukuteoriasta ja kryptografiasta?
Sähän voisit laittaa algoritmisi esille, niin katsotaan onko siinä potentiaalia vai ei. Algoritmien turvallisuus ei perustu siihen, että algoritmi olisi jotenkin piilossa urkkijoilta. MD5:a on putkapostissa ratkottu 35 kertaa ja parhaimmillaan on päästy 12 samaan merkkiin alusta.
Ilmeisesti on olemassa vielä hankalammin selvitettäviä algoritmeja. Epäileminen on aina hyvästä, mutta rajansa kaikella.
MD5,
Minua vielä hieman ihmetyttää tämä salauksien toimiminen Javassa, esim. java security luokka messagedigest taitaa, en ihan vielä ole täysin opiskellut, niin, tuo luokka kääntää salaukseen, ja ilmeisesti sitten vielä toisinkin päin, minua ihmetyttää tämä että jos sitten käännän Javalla MD5 muotoon, niin, mikä estää jotakuta tekemästä vain pientä ohjelmaa joka myös käyttää messagedigest security luokkaa, ja kääntää kaikki tietoni pois MD5 muodosta ?
Tämä MD5 turvallisuus tulee kysymykseen silloin kun minun datani on näkyvillä mutta sitä ei pysty siirtämään omaan käyttöön, liekö tuollaista tilannetta ollenkaan, jos data on näkyvillä sen yleensä myös pystyy siirtämään omaan käyttöön ja jos sen pystyy itselleensä siirtämään, niin mikä estää sitten ajamasta MD5 kääntäjää decode tarkoituksella.
Mietin nyt ensin tämän minun oman salauksen ja sitten sen päälle vielä jokin Java salaus, en niitä kaikkia vielä tunne, kenties juuri tämä MD5.
kpzpt kirjoitti:
MD5,
Minua vielä hieman ihmetyttää tämä salauksien toimiminen Javassa, esim. java security luokka messagedigest taitaa, en ihan vielä ole täysin opiskellut, niin, tuo luokka kääntää salaukseen, ja ilmeisesti sitten vielä toisinkin päin, minua ihmetyttää tämä että jos sitten käännän Javalla MD5 muotoon, niin, mikä estää jotakuta tekemästä vain pientä ohjelmaa joka myös käyttää messagedigest security luokkaa, ja kääntää kaikki tietoni pois MD5 muodosta ?
Ei ei ei ei! Md5 ja Sha1 eivät käänny taaksepäin! Se siinä on ideana!
Eli simppelisti kerrottuna:
Tarkistussumma antaa esim. jakojäännöstä muistuttavan tuloksen, joka voi tulla useammallekin eri arvolle.
Eli jos kpzpt-hash -niminen algoritmi antaisi mistä tahansa merkkijonosta kolmosen jakojäännösen (arvon 0, 1 tai 2), niin tästä jakojäännöksestä ei voi saada selville, mikä alkuperäinen salasana on ollut. Md5 ja Sha1 ei anna jakojäännöksen arvoa 0, 1 tai 2 vaan tuloksia on paljon paljon enemmän, joten alkuperäista salasanaa ei voi arvata, vaan se pitää korkeintaan "brute-forcella" "avata".
edit:
Eli et voi kaikkea tietoa "piilottaa" tarkistussummaksi, vaan voit tehdä sen esimerkiksi pelkälle salasanalle. Muut muuttujat ja arvot tuskin ovat niin arkaluontoisia, etteikö niitä saa nähdä. Esim. palvelimelle tietoa lähetettäessä voit lähettää mukaan tarkistussumman, jonka pitää tulla tietyllä tavalla muuttujat yhdistettynä, jotta palvelin suostuu tallentamaan ne.
eli pisteiden lähetys top 100 -listalle voisi sisältää seuraavat parametrit:
score = 1000
playername = kpzpt
team = ninja
hash = a4a19433ab38033089c6240e3e0b85a2
kpzpt kirjoitti:
Minua vielä hieman ihmetyttää tämä salauksien toimiminen Javassa, esim. java security luokka messagedigest taitaa
Ei ikään ihme että ihmetyttää, koska messagedigest (=tiiviste) ei ole salausta, vaikka kuuluukin kryptografian piiriin.
Message digest eli hash eli tiiviste on siis lähtökohtaisesti yksisuuntainen tapahtuma. Jos ei olisi, niin sehän olisi kätevä pakkausalgoritmi kun vaikka 17 teratavun tiedostosta tekisi 16-tavuisen tiivisteen ja sen saisi siitä palautettua takaisin alkuperäiseksi 17 teratavuksi. Matemaattisesti on triviaalia osoittaa, että tämä on mahdotonta. Kryptografisen tiivisteen tavoitteena on tehdä mahdollisimman vaikeaksi muodostaa sanoma, jonka tiiviste olisi tietty. Eri implementaatioissa voi olla muitakin tavoitteita (kuten suorituksen nopeus jollakin laitteistolla), jolloin mahdollisesti joudutaan tekemään hieman kompromissia kryptografisten ja muiden tavoitteiden välillä.
On olemassa myös ei-kryptografisia tiivisteitä, kuten CRC32. Se on optimoitu toteutettavaksi yksinkertaisella rautaratkaisulla. 2 euron piiri pystyy "laskemaan" gigatavun tiivisteen sekunnissa (esim. 1Gbps Ethernetissä). Tällaisen tiivisteen tarkoitus on vain havaita satunnaisten virheiden aiheuttamat muutokset sanomassa, ei estää jotakuta tekemästä tahallisesti erilaista sanomaa, jolla on sama tiiviste.
Salaus ja EMail,
Ok, olen ihan alussani tässä salailussa ja tarkistus summa touhussa.
Tuon salasanan MD5 on nyt sitten selkeämpi, mutta, EMail on vielä arkaluontoisampi teksti pätkä, jos joku sitten onnistuu laittamaan nettiin vaikka 1000 minun sivustoni käyttäjien email osoitetta niin se on aika noloa.
Mitenkä suositta Email piilottamisen, sehän on tieto joka tulee voida myös purkaa, minulla oli alkuun mietteissä tämä ylipiirtäminen eli satunnais lukuja byte[] muodossa tallennettuun tiedostoon jossa email ja muu tieto on, mutta siinäkin on aina se purku avain ja se löytyy java koodista taikka java runtime muuttujista ?
---
Tässä tämän päivän rakennelmat - http://temp4322.dy.fi
---
Tallenna sähköpostit (ja muutkin tiedot) johonkin muualle kuin esim. selaimella avattavaan txt-tiedostoon.
Jos ja toivottavasti kun käytät jotain tietokantaa tekstitiedostojen sijaan, sellaisesta ei tarvitse murehtia, jollet sitten ole koodannut softaasi mitään SQL-injektion mahdollistavia kohtia tai ellet ole kertonut tietokantakäyttäjän tunnuksia kaikelle maailmalle.
Ajattelitko jotakin tällaista ratkaisua, jossa on sekalainen kasa merkkejä, joista tulee selkokielinen? Tällöin kannattaa harkita jotakin valmista algoritmia / kirjastoa. Omalla työlläsi saat korkeintaan yhtä hyvän, mutta luultavasti kuitenkin huonomman ratkaisun.
Mielummin kannattaa panostaa siihen ettei kukaan pääse käsiksi tietoihin.
Macro kirjoitti:
Jos ja toivottavasti kun käytät jotain tietokantaa tekstitiedostojen sijaan
Tähän vähän yritinkin viitata jo useamman kerran.
Lisäys:
Miten mulla on muuten jäänyt jotenkin semmonen kuva, että hakisit kaikki käyttäjätiedot kerralla pelaajien clientillä, josta vasta tarkistaisit esim. sisäänkirjautumistiedot?
Yksi astetta ovelampi vaihtoehto toki olisi, että ei varastoi sähköpostiosoitteita palvelimella lainkaan. Salasanavaihtoviestin lähettäminen sähköpostiinkin on mahdollista toteuttaa ilman, että sähköpostiosoitteen täytyy olla selväkielisenä tai salattuna palvelimella (tiiviste riittää).
Tai voisit salata ne julkisella avaimelle ja jos joskus tarvitset jonkun käyttäjän sähköpostin niin voisit purkaa sen vaikka kotikoneella käyttäen salaista avaintasi joka ei ole lainkaan palvelimella.
