Millä ohjelmointikielillä olisi mielestänne kannattavinta lähteä toteuttamaan seuraavanlaista ohjelmaideaa:
(ohjelmointi ei ole itselleni tuttua joten alla voi olla kysymystä ajatellen täysin epärelevantteja asioita)
-Ohjelma hakee ruudulle tietopankista 3D objekteja, joita käyttäjä voi itse pyöritellä näytöllä
-toimii OSX:llä ja windowsilla
-kaikki toiminnot tapahtuvat viiveettä (onko tähän kielellä sitten vaikutusta noin yleensä koneen tehojen ohella?)
-toimii peruskoneilla ilman mitään lisäohjelmistoja
-toistaa animaatiopätkiä
Heittäkää myös karkea arvio, kuinka kauan tarvisi ojelmointia opiskella, ennenkö ylläolevan kaltaisen ohjelman pystyy toteuttamaan esim. Pythonilla tai Javalla?
Jos päämäärä olisi siis oppia juuri sen verran että pystyy tuon toteuttamaan, ei mitään syvempää tai ylimääräistä hässäkkää.
Tarkoitukseen sopiva ohjelmointikieli?
22
157
Vastaukset
- adfasdasdadsdas
"toimii peruskoneilla ilman mitään lisäohjelmistoja"
Mitä tarkoitat lisäohjelmistoilla? Python tarvitsee tulkin ja java tarvitsee java virtuaalimasiinan. Tämän lisäksi monet kirjastot antavat paljon apua ja ihan kaikkea ei tarvitse tehdä käsin
Tuossa simppeli esimerkki 3d kuution pyörittämisestä pythonilla. Vastaavia esimerkkejä löydät kiellelle kuin kielelle ja voit tehdä oman valintasi kielestä jota haluat käyttää
http://codentronix.com/2011/05/12/rotating-3d-cube-using-python-and-pygame/ - Javaw
No kielellä ei niin ole väliä, vaan grafiikkakirjastolla. Jos laitteistoriippumattomuutta haetaan, niin OpenGL on oikeia valinta.
Suosittelisin kyllä C , riittää kun osaa perusteet, OpenGL:ää pitää sitten osata enemmän.
Ihan mahdolliseltahan tuo kuulostaa, vuoden aktiivinen opiskelu alkaa varmasti tuottaa tulosta.- Javaw
Ja lisäys vielä, että jos objektit ovat kovin monimutkaisia, niin kielten nopeuserot alkavat jo näkyä. En lähtisi tuollaista kyllä Javalla toteuttamaan.
"No kielellä ei niin ole väliä, vaan grafiikkakirjastolla. Jos laitteistoriippumattomuutta haetaan, niin OpenGL on oikeia valinta."
Ei vaan WebGL. Windowsissa OpenGL on deprekoitu ja siinä ohjelmoidaan DirectX:ää C#:lla. Mac OS:ia taas ei ohjelmoida C#:lla.
WebGL sen sijaan on molemmissa täysin tuettuna ja sitä voi ohjelmoida molemmissa Javascriptillä.Javaw kirjoitti:
Ja lisäys vielä, että jos objektit ovat kovin monimutkaisia, niin kielten nopeuserot alkavat jo näkyä. En lähtisi tuollaista kyllä Javalla toteuttamaan.
Java on hyvin nopea kieli, ei ole nopeudesta kiinni se. Javan ongelma on se, että se toimi kaikissa päätelaitteissa ja voi tarvita erillistä ajoympäristöä. Se on siis väärä työkalu.
- Javaw
M-Kar kirjoitti:
"No kielellä ei niin ole väliä, vaan grafiikkakirjastolla. Jos laitteistoriippumattomuutta haetaan, niin OpenGL on oikeia valinta."
Ei vaan WebGL. Windowsissa OpenGL on deprekoitu ja siinä ohjelmoidaan DirectX:ää C#:lla. Mac OS:ia taas ei ohjelmoida C#:lla.
WebGL sen sijaan on molemmissa täysin tuettuna ja sitä voi ohjelmoida molemmissa Javascriptillä.Mtä vttua selität? Ei ole OpenGL:ää paprikoitu Windowsissa, ihan vaan OpenGL:ää ohjelmoidaan. Sitä paitsi nyt ei varmaankaan haluta mitään web-sovellusta.
- jööö
"Mitä tarkoitat lisäohjelmistoilla? Python tarvitsee tulkin ja java tarvitsee java virtuaalimasiinan."
Siis että jos olet käyttäjä joka asentaa kaupatun ohjelman koneellensa, ettei sen toimivuus olisi kiinni jatkuvista päivityksistä esim. grafiikantoistoa ajatellen.
Jäi joitakin seikkoja mainitsematta ensimmäisessä viestissä. 3D-objektit olisi siis valmista itsetuotettua grafiikkaa. Lisäksi joitain lyhyitä animaatioita objekteihin liittyen. Eikö tämä periaattessa vähentäisi ohjelmointimäärän tarvetta, jos kaikki visuaaliset tapahtumat olisi valmiina ja valmiiksi animoituja? Eikö siis tällöin voisi antaa tavallaan vain käskyn jonkin valmiin (video)tiedoston toistamiseen? Jos nyt ollenkaan ymmärsin mitä siis viesteissänne tarkoititte.
Esineen pyörittelyn mahdollistaminen on on varmaan tätä mutkikkaampi koodata. Siis että valmiin ohjelman käyttäjällä olisi mahdollisuus pyörittää objektia. Mutta onko ohjelmointia ajatellen tällöinkään merkitystä objektin ulkonäöllä, jos se on valmiiksi renderöity?
Aloittelijoille tarkoitetuissa artikkeleille missä puhutaan kielien eroista ym. seikoista näyttäisi olevan yhteistä se, että niissä käytetään heti alusta lähtien termejä minkä merkityksiä ei ole vielä seivitetty, ja jos ne selitetään niin vaikkakin osataan selittää asian rakennetta hierarkisesti niin selityksissä käytetään uusia termejä mitä ei ole vielä selitetty. Sinänsä mielenkiintoista näinkin loogista etenemistä vaativassa opissa. Mutta ei kyllä pitäisi koittaa sönköttää liikoja vaan vaan lueskella lisää." Eikö tämä periaattessa vähentäisi ohjelmointimäärän tarvetta, jos kaikki visuaaliset tapahtumat olisi valmiina ja valmiiksi animoituja? Eikö siis tällöin voisi antaa tavallaan vain käskyn jonkin valmiin (video)tiedoston toistamiseen? Jos nyt ollenkaan ymmärsin mitä siis viesteissänne tarkoititte."
Missä muodossa se animaatio/video olisi?
"Esineen pyörittelyn mahdollistaminen on on varmaan tätä mutkikkaampi koodata. Siis että valmiin ohjelman käyttäjällä olisi mahdollisuus pyörittää objektia. Mutta onko ohjelmointia ajatellen tällöinkään merkitystä objektin ulkonäöllä, jos se on valmiiksi renderöity?"
Vapaata pyörittelyä ei käytännössä saa valmiiksi renderöityä. Vaatii järkyttävän määrän kuvia.
- jööö
Aloittelijoille tarkoitetuille*
"-toimii OSX:llä ja Windowsilla"
Javascript on ainoa järkevä päätelaittessa käytettävä multiplatform kieli, sillä muita kieliä rajoitetaan kaiken aikaa.
"-toimii peruskoneilla ilman mitään lisäohjelmistoja"
Javascript on silloinkin oikea työkalu kun muilla tarvitsee jotain ohjelmien asentelua tai jopa ajoympäristöjen asentamista enste.
"-kaikki toiminnot tapahtuvat viiveettä (onko tähän kielellä sitten vaikutusta noin yleensä koneen tehojen ohella?)"
On. Tällä hetkellä Javascript on noin luokkaa 10x hitaampi kuin natiivi. Eriasia sitten onko sillä mitään merkitystä kun tarvitsisi aika raskasta prosessointia että sitä huomaa.- Jööö
Olisiko kellään heittä esimerkkejä minkälaisia palkkioita ohjelmoijille on maksettu jotain pikkuohjelmistoja koskien koko projektin osalta?
Tuntipalkkoja kyllä löytyy, mutta käyännössä, ei mitään käsitystä kuinka kauan minkäkintyyppisen ohjelman ohjelmoimiseen kuluu, tietenkin kiinni ohjelmoijasta mutta keskimäärin tai esimerkkejä? Voin ehkä myös googletella.Yksinkertainen tapa arvioida aikaa on se kun miettii millainen ohjelmoijan työpäivä on. Se että saa fokuksen siihen työhön kestää hetken, joten keskeytykset ovat ikäviä mutta niitäkin tulee ja hävikkiaikaa ei voi missään työssä täysin välttää ja joskus ihmiset myös mokailevat. Ohjelmoija ohjelmaa tehdessä kirjoittaa testejä, ja kirjoittaa koodia joita ne testit testaavat sekä korjaa vikoja. Työpäivän aikana saa hoidettua ehkä noin 12 asiaa, joista yksi asia on noin puoli tuntia. Tehollista aikaa tulisi siis 6h. Työpäivästä menee loput 1.5h kommunikointiin asiakkaan kanssa, syömiseen, sähköpostit, kahvitaukoon, paskanjauhantaan, jonkun ylläripylläri bugien korjaamiseen, muutama minuutti facebookkia aivojen virkistämiseksi tai johonkin muuhun säätöön.
Tästä noin 12 hoidetusta asiasta saadaan jos olisi vaikka 6kpl kirjoitettuja testejä, ja 6kpl toiminnallisuutta joita ne testit hoitavat.
Jos on viiden päivän työviikko, viikossa pitäisi siis saada ohjelmaan tehtyä noin luokkaa 30 juttua per kehittäjä.
Eli, se hintalappu menee siis sen mukaan, kuinka monimutkaisen ohjelman haluat! Kaikki monimutkaisuus lisää niitä testien kuin toiminnallisuuksien kirjoittamista.
Koko projekti pitää aloittaa miettimällä, että:
1. Mistä ja mitä tietoa tuodaan ohjelmaan sisään
2. Mitä tietoa ja minne ohjelmasta pitäisi saada ulos
3. Mitä tietoa ja minne ohjelman pitäisi tallentaa
4. Hahmoittamalla käyttöliittymänäkymiä niin loppukäyttäjän kuin hallintanäkymän puolelta, että mitkä napit siellä on ja mitä niiden pitäisi tehdä.
5. Kuvaus tallennettavista tiedoista esim. taulukkolaskentaohjelman tiedostoina, että taulukosta näkisi mitä kenttiä on tietoa
6. Määrittelemällä milloin ohjelma on valmis. Eli pitäisi muotoilla hyväksymistestit ja ohjelma on valmis sitten kun kaikki hyväksymistestit menee läpi.
Pointti siis on se, että pitäisi tietää ihan tarkkaan mitä halutaan, ja se pitää vielä muotoilla kirjallisesti, yksiselitteisesti ilman tulkinnanvaraisuuksia. Sitten vasta hahmoittaa sen monimutkaisuuden.
((((
Tässä lainausta hyväksymistestausten tekemisestä:
Sam: “OK, now these log files need to be backed up.”
Paula: “OK, how often?”
Sam: “Daily.”
Paula: “Right. And where do you want it saved?”
Sam: “What do you mean?”
Paula: “Do you want me to save it a particular sub-directory?”
Sam: “Yes, that’d be good.”
Paula: “What shall we call it?”
Sam: “How about ‘backup’ ”?
Tom (tester): “Wait, backup is too common a name. What are you really storing in this directory?”
Sam: “The backups.”
Tom: “Backups of what?”
Sam: “The log files.”
Paula: “But there’s only one log file.”
Sam: “No, there are many. One for each day.”
Tom: “You mean that there is one active log file, and many log file backups?”
Sam: “Of course.”
Paula: “Oh! I thought you just wanted a temporary backup.”
Sam: “No, the customer wants to keep them all forever.”
Paula: “That’s a new one on me. OK, glad we cleared that up.”
Tom: “So the name of the sub-directory should tell us exactly what’s in it.”
Sam: “It’s got all the old inactive logs.”
Tom: “So let’s call it old_inactive_logs.”
Sam: “Great.”
Tom: “So when does this directory get created?”
Sam: “Huh?”
Paula: “We should create the directory when the system starts, but only if the directory doesn’t already exist.”
Tom: “OK, there’s our first test. I’ll need to start up the system and see if
the old_inactive_logs directory is created. Then I’ll add a file to that directory. Then I’ll shut down, and start again, and make sure both the directory and the file are still there.”
Paula: “That test is going to take you a long time to run. System start-up is already 20 seconds, and growing. Besides, I really don’t want to have to build the whole system every time I run the acceptance tests.”
Tom: “What do you suggest?”
Paula: “We’ll create a SystemStarter class. The main program will load this starter with a group of StartupCommand objects, which will follow the Command pattern. Then during system start-up the SystemStarter will simply tell all the StartupCommand objects to run. One of those StartupCommand derivatives will create the old_inactive_logs directory, but only if it doesn’t already exist.”
Tom: “Oh, OK, then all I need to test is that StartupCommand derivative. I can write a simple FitNesse test for that.”Tom goes to the board.
“The first part will look something like this”:
given the command LogFileDirectoryStartupCommand
given that the old_inactive_logs directory does not exist when the command is executed
then the old_inactive_logs directory should exist
and it should be empty
“The second part will look like this”:
given the command LogFileDirectoryStartupCommand
given that the old_inactive_logs directory exists
and that it contains a file named x
When the command is executed
Then the old_inactive_logs directory should still exist
and it should still contain a file named x
Paula: “Yeah, that should cover it.”
Sam: “Wow, is all that really necessary?”
Paula: “Sam, which of these two statements isn’t important enough to
specify?”
Sam: “I just mean that it looks like a lot of work to think up and write all
these tests.”
Tom: “It is, but it’s no more work than writing a manual test plan. And it’s much more work to repeatedly execute a manual test.”
))))
Eli, määrittele mitä haluat ensiksi. Niin tarkasti ja yksiselitteisesti niin selviää se kompleksisuus. Jos et määrittele tarkasti vaan teetät ohjelmaa puutteellisella määrityksellä, niin saat sitä projektisuunnitelmaa takaisin bumerangina useaan otteeseen jossa kehittäjät tarkentaa niitä vaatimusta, aika-arvion kasvaessa.
Sitten kun ohjelma on "valmis" ja testaat sitä niin huomaatkin että "ei se nyt näin vaan tarvisi tähän tälläinen muutos". Ja siitä tulee sitten uutta "sinne päin" aika-arviota. Epämääräisillä määrityksillä on tapana mennä niin, että varataan vaan rahaa tarpeeksi ja kehitystä tehdään niin pitkälle kuin raha riittää, tuli sitten mitä tuli.
Eli, määrittele tarkasti mitä haluat ja mikä on "valmis". Sitten ei ole tulkinnanvaraisuuksia ja hintalappu tulee tarkaksi. Ongelma kannattaa myös purkaa riittävän pieniin osiin, eli käyttöliittymä, palvelimessa oleva osa, datakonversiojutut jne. ovat erillisiä projekteja eikä edes yritä käsittää koko hoitoa yhtenä projektina.M-Kar kirjoitti:
Tom goes to the board.
“The first part will look something like this”:
given the command LogFileDirectoryStartupCommand
given that the old_inactive_logs directory does not exist when the command is executed
then the old_inactive_logs directory should exist
and it should be empty
“The second part will look like this”:
given the command LogFileDirectoryStartupCommand
given that the old_inactive_logs directory exists
and that it contains a file named x
When the command is executed
Then the old_inactive_logs directory should still exist
and it should still contain a file named x
Paula: “Yeah, that should cover it.”
Sam: “Wow, is all that really necessary?”
Paula: “Sam, which of these two statements isn’t important enough to
specify?”
Sam: “I just mean that it looks like a lot of work to think up and write all
these tests.”
Tom: “It is, but it’s no more work than writing a manual test plan. And it’s much more work to repeatedly execute a manual test.”
))))
Eli, määrittele mitä haluat ensiksi. Niin tarkasti ja yksiselitteisesti niin selviää se kompleksisuus. Jos et määrittele tarkasti vaan teetät ohjelmaa puutteellisella määrityksellä, niin saat sitä projektisuunnitelmaa takaisin bumerangina useaan otteeseen jossa kehittäjät tarkentaa niitä vaatimusta, aika-arvion kasvaessa.
Sitten kun ohjelma on "valmis" ja testaat sitä niin huomaatkin että "ei se nyt näin vaan tarvisi tähän tälläinen muutos". Ja siitä tulee sitten uutta "sinne päin" aika-arviota. Epämääräisillä määrityksillä on tapana mennä niin, että varataan vaan rahaa tarpeeksi ja kehitystä tehdään niin pitkälle kuin raha riittää, tuli sitten mitä tuli.
Eli, määrittele tarkasti mitä haluat ja mikä on "valmis". Sitten ei ole tulkinnanvaraisuuksia ja hintalappu tulee tarkaksi. Ongelma kannattaa myös purkaa riittävän pieniin osiin, eli käyttöliittymä, palvelimessa oleva osa, datakonversiojutut jne. ovat erillisiä projekteja eikä edes yritä käsittää koko hoitoa yhtenä projektina.Eli kuten näit niin tuollainen logitoiminnallisuus vaatisi 10 testiä, eli puhutaan alle kahden työpäivän jutusta.
Vaikea sanoa mikä tässä kyseisessä jutussa on tavoitetila, että onko kyse tuotekehityksestä vai halutaanko omaan käyttöön työkalua mutta yleisesti ottaen halvinta on käyttää valmiita ohjelmia. Ja jotta saa vähän perspektiiviä niin silloin ei yleensä kannata määritellä useita käyttöjärjestelmiä tms. kun on yleensä halvempaa ostaa uudet tietokoneet ja uudet valmisohjelmat kuin teettää kokonaan uusi ohjelma."Olisiko kellään heittä esimerkkejä minkälaisia palkkioita ohjelmoijille on maksettu jotain pikkuohjelmistoja koskien koko projektin osalta?"
Ensiksi tosiaankin kannattaa purkaa se ongelman laajuus, että kuinka pientä ohjelmistoa haetaan. Jokainen eri muotoista tietoa tallentava & käsittelevä osa on yksi komponentti, esim. palvelu joka huolehtii siitä 3D-mallitietopankista on yksi ohjelma.
Jos dataa täytyy tuoda tähän tietopankkiin jostain, jokaisen datamuodon tekevä konvertteri on yksi oma ohjelma.
Jokainen käyttöliittymä, niin se loppukäyttäjän näkymä, animaatioplayeri kuin joku ylläpito käyttöliittymä, on oma ohjelmansa.
Siitä voit laskea monta pikku ohjelmaprojektia siihen kokonaisuuteen kuuluu, jotka pitää purkaa osiin, määritellä ja tehdä pala kerrallaan.
- jööö
Kiitokset selvennyksestä, avasi ihan hyvin ohjelmoijankin näkökulmasta asiaa vaikken itse siitä juurikaan tiedä. Tavoitteen tarkkojen ominaisuuksien määrittely ei olisi varmastikaan ongelma, ja se olisi omasta mielestäni ohjelmana todella simppeli, vaikkakin tarkoitukseensa tehokas apuväline.
Yksi asia jota en saa päästäni on se, että olisiko joihinkin ohjelmointikieliin mahdollista tavalla tai toisella importata 3D-mallit jotka on mallintanut 3D-ohjelmalla valmiiksi. Aiemmin sekoilin jotain renderöidyistä malleista mutta eihän siinä tietenkään ole mitään järkeä jos puhutaan kappaleesta jota voi pyörittää ruudulla joka suuntaan.
Eli kuinka saada ohjelman ruutuun tekstuureineen ulkonäöltään yhtäläinen interaktiivinen objekti jonka on suunnitellut 3D-ohjelmalla? Varmaankin hankalempi homma. Niin... kyllähän tämä jotenkin peleihinkin toteutetaan."Yksi asia jota en saa päästäni on se, että olisiko joihinkin ohjelmointikieliin mahdollista tavalla tai toisella importata 3D-mallit jotka on mallintanut 3D-ohjelmalla valmiiksi."
Mikään ohjelmointikieli itsessään ei tajua mitään 3D-malleista. Ohjelmointikieli on työkalu jolla tehdään ohjelma joka lukee jollain 3D-ohjelmalla luodun mallin muistiin johonkin tietorakenteeseen. Sitten kun se 3D-malli on muistissa, voidaan ohjelmointikielellä tehdä ohjelma joka piirtää sen mallin ruudulle.
Sitä saattaa tietysti löytyä valmiita komponentteja tällaiseen, joko maksutta tai maksamalla. Valmis komponentti tietysti tekee riippuvuuden siihen ja se voi tehdä rajoitteita.
Mutta, ohjelmointihan on sitä tehdään sitä ohjelmaa joka esimerkiksi lukee jonkun 3D-mallin muistiin. Näitä asioitahan tässä projektissa ollaan selvästikin hakemassa.
"Eli kuinka saada ohjelman ruutuun tekstuureineen ulkonäöltään yhtäläinen interaktiivinen objekti jonka on suunnitellut 3D-ohjelmalla? Varmaankin hankalempi homma"
Ihan vaan ohjelmoimalla. 3D-mallin formaatti pitäisi toki tietää, että lukee siitä tiedostoformaatin spesifikaatiosta mitä se pitää sisällään, sitten kirjoittaa ohjelman joka lukee sen muistiin. Eiköhän siellä ole läjä koordinaatteja vertekseille, tekstuurikoordinaatit jne.
- jööö
... Eli renderöikö pelimoottorit kunkin kuvan ruudulle reaaliajassa? Ja kun ajatellaan tavoitetta että grafiikka olisi samaa laatua mikä kestää 3D-softalla renderöidä 5min/kuva, ei varmaan tässä tapauksessa tule tapahtumaan.
- jööö
Noniin jollain tapaa onnistunut sen pelisuunnitteluasian jättämään ilman kummempaa huomiota vaikka tullut noita 3D-foorumeita seilailtua jonkin verran jo.
Taitaa siis olla niin että ei ole muuta ainakaan peleissä yleisesti käytettyä tapaa saada sitä interaktiivista grafiikkaa kun reaaliaiakaisella renderöinnillä, ja jotain valmiiksi laskelmoituja ominaisuuksia mitä pelimoottorit lyö ruutuun.
Eli tavoitetta ajatellen ei ole järkevää lähteä lähestymään asiaa tästä suunnasta.Aina siellä jokin reaaliaikainen piirtovaihe on mutta osa jutuista voidaan myös esirenderöidä. Näin on tehty vuosikymmeniä.
- sanonminäkunsanon
openGL ja joku c, on c ja openGL
- jööö
tattista
Ketjusta on poistettu 0 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
Metsäkoneen kuljettaja huuteli tutkijalle
"voisit kyllä ottaa rintaliivit pois ennen kuin tulet minulle juttelemaan, hän sanoo." https://yle.fi/a/74-20106446 On70410030Suomi on täysin sekaisin
Jo ties monettako päivää hirveä itku ja poru jostain helvetin nilviäisistä. https://www.is.fi/taloussanomat/art-20000104124390Kaikki ei vieläkään usko luontokatoon.
Suomussalmen Hukkajoella foliohattu metsäkoneen kuljettaja tuhosi tuhansia harvinaisia jokihelmisimpukoita eli raakkuja903016Sano vain suoraan, että nyt riittää
ettei kiinnosta. Sano, että lopeta! En ihmettelisi, jos olet saanut tarpeeksesi ja toivot minun ymmärtävän lopettaa. Eh432855Mari Rantanen asettaa sairaan lapsen edun oman uransa edelle - (tekikö Marin samaa)
Noin toimii kunnon vastuuntuntoinen äiti, mutta siitäkin nämä mt-ongelmaiset vasemmistolaiset häntä täällä haukkuvat. "2302668Ohhoh! Ex-pääministeri Sanna Marinin Joni-rakas paljasti ilouutisen: "Tässä kuussa..."
Sanna Marin on ollut naimisissa Markus Räikkösen kanssa. Nyt hänen seurassaan on usein julkkishiusmuotoilija Joni Willb552664- 1531855
Luokatonta toimintaa
Tyrmistyttävää toimintaa Stora Enson korjuu yrittäjältä Hukkajoella. Täyttä piittaamattomuutta laeista ja luontoarvoista711710Ensimmäisestä kohtaamisesta saakka
minulla on ollut hämmentynyt olo. Miten voit tuntua siltä, että olisin tuntenut sinut aina? Sinun kanssasi on yhtä aikaa141620Maailmankuulu homopingviini on kuollut
Minä niin toivoin että pariskunta olisi saatu kunniavieraiksi ensi kesän Prideen. 💔 "Maailmankuulu homopingviini on k61423