http://www.siforge.org/articles/forum/../../articles/2004/04/19-sdl_image.html Commenti all'articolo "Gestire immagini con SDL: SDL_Image " it redazione@siforge.org redazione@siforge.org http://www.siforge.org/images/skin/default/sidebar/icon32.gif http://www.siforge.org/ http://www.siforge.org/articles/forum/index.cgi/show/t20040419__sdl_image#73176447 ciao raga per favore, mi sapreste fare un esempio di come si usa cin.get e come si usa lo switch?grazie!! http://www.siforge.org/articles/forum/index.cgi/show/t20040419__sdl_image#23108105 Ciao Igor, gli articoli per SIForge sono sempre bene accetti, soprattutto su una tematica come le Xlib che sicuramente e` "terreno per esperti"! ;) http://www.siforge.org/articles/forum/index.cgi/show/t20040419__sdl_image#70594736 ciao! ho appena scaricato e provato il nuovo esempio di scrolling...bello! scritto molto bene ....e ho trovato interessante il meccanismo con cui la velocita' di scorrimento non dipende dal numero di frame al secondo ma dal tempo trascorso dall'ultimo refresh...un modo elegante di effettuare il frameskipping! come velocita'....sulla macchina che sto usando in questo momento ottengo dagli 80 ai 90 fps...un risultato adeguato, comunque non mi e' ancora capitato di trovare un computer che usi effettivamente HW_SURFACE, con la funzione che mi ritorna le info del display vedo sempre video_mem=0. vabeh...per ora rimango sulle Xlib (se interessa qualche esempio o addirittura qualche articolo per Siforge fatemelo sapere, in effetti non ho nemmeno uno spazio per pubblicare tutti i miei sorgenti e non ho ancora organizzato tutto quello che ho imparato fin'ora) Per quanto riguarda le collisioni, ho gia' pronte un paio di routine, una classica bounding box e una piu' precisa per le collisioni al pixel, che pero' al momento funziona solo se i due sprite hanno le stesse dimensioni! http://www.siforge.org/articles/forum/index.cgi/show/t20040419__sdl_image#88444837 Ciao Igor, come promesso ho pubblicato sul sito di Mars (http://mars.sourceforge.net/down.php?dow=e) un nuovo esempio basato sull'ultima versione di scrolling che ho realizzato, se lo scarichi e lo provi, magari fammi sapere come va ;) http://www.siforge.org/articles/forum/index.cgi/show/t20040419__sdl_image#44551912 Ciao Igor, credo di aver terminato il programma per lo scrolling (adesso arriva a 108 FPS sempre con gestione del mouse), credo di pubblicarlo nella sezione degli esempi SDL di Mars quanto prima, tieni d'occhio il sito. Ad ogni modo per rispondere alle varie domande posso dirti che se hai intenzione di realizzare qualcosa che sia real time, devi utilizzare necessariamente opengl. Per quanto riguarda la tecnica di updateRect è ovvio che durante lo scrolling equivale a chiamare una Flip (a meno che non hai aree fisse come ad esempio un pannello di controllo), ma durante movimenti di sprite, o cmq di componenti che interessano solo parte dello schermo in genere conviene sempre. Per le collisioni non ti posso ancora aiutare, visto che non ho ancora affrontato l'argomento, ti farò sapere in seguito. Cya http://www.siforge.org/articles/forum/index.cgi/show/t20040419__sdl_image#32752191 riciao! e ri-complimenti per i 102 fps in 800x600...mi ero dimenticato di dire che i miei erano in 640x480. Spero che pubblicherai il codice quando avrai finito questa routine perche' mi interessa molto! Per quanto riguarda le considerazioni generali, sono d'accordo che bastano anche meno FPS, gia' 60 sarebbero un ottimo risultato, pero' volevo tenermi del "tempo macchina" per gestire tutto il resto...la mia idea e' di realizzare un gioco di ruolo con personaggi non giocanti un po' piu' realistici della media e un mondo consistente. Grazie per il suggerimento di usare SDL_UpdateRect, pero' nel caso di una routine di scrolling dello sfondo, in pratica ogni pixel della finestra sara' diverso per ogni frame. Quindi ogni volta bisogna ridisegnare tutto, no? O si puo' fare come nei bei vecchi tempi e lavorare direttamente sulla memoria video, dicendo alla cpu di disegnare solo a partire da un certo indirizzo? Altrimenti mi sa che dovro' mettere le mani anche sulle openGL e "spalmare" il tutto su una texture per poi cambiare il punto di vista. Cambiando discorso, hai qualche dritta per implementare le collisioni al pixel? Le xlib offrono alcune funzioni piuttosto potenti in questo caso! http://www.siforge.org/articles/forum/index.cgi/show/t20040419__sdl_image#04049899 Ciao Igor, grazie per i complimenti ;) Per rispondere alla tua domanda posso dirti che con SDL non riuscirai mai a raggiungere le prestazioni di librerie a basso livello come ad esempio xlib, in particolare perchè SDL si basa quasi totalmente sul processore, pertanto basta avere un paio di applicazioni "pesanti" in esecuzione per notare forti degradi di prestazioni. Non hai specificato la risoluzione che stai usando (il che può far variare notevolmente il numero di FPS), ad ogni modo posso dirti che proprio in questo periodo lavorando ad un programma di scrolling sono in grado di raggiungere tranquillamente i 102 FPS (non usando delay) facendo muovere una grande img sullo sfondo in una finestra 800x600. Cmq i FPS non devono essere l'unico parametro di riferimento, dopotutto l'occhio umano non è in grado di percepirne un numero molto elevato, pertanto l'importante nello sviluppo di applicazioni multimediali (giochi e simili) è ottenere una fluidità nell'immagine piacevole alla vista, cosa che nell'ultima versione del mio programma riesco ad ottenere sugli 80 FPS. Avere un buon numero di FPS è senza dubbio una cosa positiva, però l'importante è cercare di mantenere costante il numero di pixel di spostamento per ms. Oltre questo accorgimento per la fluidità puoi utilizzare tecniche di ottimizzazione come ad esempio l'utilizzo di SDL_UpdateRect al posto di SDL_Flip, aggiornando solo le aree modificate (quindi gravando meno il processore). Ad ogni modo appena avrò finito le mie sperimentazioni vedrò di scrivere una guida sullo scrolling e sulle ottimizazioni varie. Un'ultima cosa, prestazioni ottimali si possono ottenere soltanto utilizzando openGL, quindi tieni in considerazione i limiti "fisici" della libreria (non a caso SDL è una base per openGL in applicazioni serie). P.S. Marco forse sono riuscito ad ottenere una versione decente dello scrolling, appena ho finito i test te la mando ;) http://www.siforge.org/articles/forum/index.cgi/show/t20040419__sdl_image#31666893 SDL e` una libreria ad alto livello che si prefigge di girare su diversi sistemi operativi, l'implementazione per Linux e` sicuramente basata sulle Xlib. E` dunque prevedibile che non sia cosi` performante quanto un'applicazione nativa Xlib, l'ovvio vantaggio e` che ti riduce le problematiche di porting su sistemi non X-Window. L'elevata discrepanza nell'ultimo potrebbe essere legata ad algoritmi specifici per ottimizzare il refresh o tare di questi. Ciao, Marco http://www.siforge.org/articles/forum/index.cgi/show/t20040419__sdl_image#28445648 ciao! ottimi tutorial! ho pero' una perplessita'...io ho sempre usato le xlib per scrivere semplici applicazioni grafiche e qualche giochino...uno dei miei "esperimenti" consiste in una routine di scrolling per un gioco 2d con fondale a "tiles". allora...con le xlib, senza particolari ottimizzazioni, riesco a ottenere circa 150 frame al secondo. Nelle stesse condizioni (stessa dimensione della finestra...stessa profondita' colore, stesse tiles, ecc), con le SDL ne ottengo al massimo 60. Ho usato le flagh HW_SURFACE e DOUBLEBUF e l'accortezza di chiamare SDL_DisplayFormat() eccetera. c'e' modo di migliorare le prestazioni? Anche il semplice refresh della finestra senza "metterci dentro" nulla, e' molto piu' veloce con le Xlib (3600 fps) piuttosto che con le SDL (circa 80), quindi non dipende dalla (ancora da migliorare) routine che piazza le tiles al loro posto! O dipende dall'implementazione e dall'hardware che uso? http://www.siforge.org/articles/forum/index.cgi/show/t20040419__sdl_image#93931232 Sinceramente la cosa mi pare strana, soprattutto considerando che in modalità finestra ti funziona ed a tutto schermo no, ma soprattuto considerando che il programma era stato testato anche sotto win, anche se non ricordo se con il DEV o con il Cygwin. Comunque l'importante è che tutto sia stato risolto. Per quanto riguarda la nuova gestione dei tasti ti assicuro che risparmiare una chiamata ad una function (qualunque essa sia) è sempre un vantaggio, questo anche se si deve occupare una ventina di byte di memoria in più. http://www.siforge.org/articles/forum/index.cgi/show/t20040419__sdl_image#54410285 Ciao Davide, ti assicuro che il bug c'era, compilando il vecchio sorgente su windows col Dev-C++ (www.bloodshed.net), se vuoi posso mandarti in mail l'exe ottenuto cosi' (basta che chiedi a Marco il mio indirizzo e che mi contatti). In pratica andando in full screen *bg refresha malissimo, lo si vede bene solamente nelle zone dove il carro e' gia' passato (in virtu' della tecnica che usavi di estrapolare un SDL_Rect attorno al tank dal bg e di ricopiarlo sulla scia del tank). Mentre ora non usando piu i rect in questa maniera ma, alla riga 220 //si ridisegna lo sfondo per coprire le scie degli spostamenti SDL_BlitSurface(bg, NULL, screen, NULL); hai fatto quello che dicevo di aver fatto io in precedenza: (ri)disegni lo sfondo assieme alle altre Surface. Se commenti quella riga, oltre alla scia del tank (che appunto non si vedeva nel vecchio sorg) ottieni lo stesso effetto al bg che ottenevo io precedentemente. Se tu su slackware non avevi questo genere di problema, potrebbe essere una differenza di implementazione di SDL sulle 2 piattaforme... altro non so che pensare... (Dev e' un porting di gcc sotto win... non credo il problema sia la') Per il discorso di event, non conosco le specifiche della gestione tasti in sdl, e quindi quanta 'fatica' fa la chiamata aggiuntiva a SDL_GetKeyState. Tu hai istanziato 3 int in piu, 4 case a un costrutto switch che c'era gia' e un costrutto switch con 4 case nuovo. Cmq ti ringrazio nuovamente x il tut ! http://www.siforge.org/articles/forum/index.cgi/show/t20040419__sdl_image#46562044 Ciao Federico, grazie per i complimenti, passiamo alle risposte. Sinceramente non capisco a che bug tu ti riferisca visto che il programma descritto nella versione precedente della guida era perfettamente funzionante, infatti la riscrittura è stata effettuata non per corregere bug, ma per migliorare il codice esistente. Per quanto riguarda il nuovo tipo di gestione dei tasti premuti, la risposta è semplice, ovvero l'ottimizzazione. Credo che converrai con me che è decisamente meglio fare gestire un evento al gestore apposito, piuttosto che chiamare una function in più (SDL_GetKeyState) ad ogni iterazione del main loop. Spero di aver chiarito i tuoi dubbi. P.S. X Marco: nella sezione che segnala gli aggiornamenti degli articoli non mi pare ci sia la segnalazione della modifica all'articolo in questione, puoi provvedere? Thanx ;) http://www.siforge.org/articles/forum/index.cgi/show/t20040419__sdl_image#75536653 Ciao, complimenti x il tutorial. Lo sto studiando in relazione a un progetto che ho con amici, e nn avendo mai provato a usare sdl (pur conoscendole da molto di fama) mi siete stati di grande aiuto. Solo una curiosita' in relazione alla modifica del codice avvenuta in questi giorni: L'unica differenza sostanziale dal sorgente precedente che ho visto e' stata l'eliminazione del bug nel refresh dello sfondo a full screen, dovuta al posizionamento del primo DrawImage() del bg su screen prima di tutti i cicli di verifica e modifica del tank. L'avevo risolto mettendo quel draw assieme a tutti gli altri in fondo, ma nn ho postato xche' x uno che apprende, mettersi a ragionare in prima persona sul tanketto aiuta a schiarirsi le idee in altri campi ^^. Insomma un difetto educativo che sono sicuro non ripetero' io stesso in futuro essendomici gia' rotto la testa. Ora volevo chiedere, il perche' della nuova verifica di event.type == SDL_KEYUP ! Insomma il codice funzionava gia prima, e dalla semplicissima pila SDL_GetKeyState(NULL) siete passati a gestire le key col event. Personalmente mi e' stato utilissimo poter vedere i diversi metodi per ottenere le keydown, ma non capisco proprio il perche' dell'aggiunta delle keyup ai fini pratici. Parlo sempre in generale di questi metodi x eventuali applicazioni che vorrei creare io. Cerca negli articoli pubblicati s_query http://www.siforge.org/articles/search/