MIB

In questa zona vengono raccolte le discussioni che riguardano lo sviluppo di nuovi progetti per ARM e per Re-Volt

Moderatore: Michelangelo

Avatar utente
Vas0sky
Utente
Messaggi: 1856
Iscritto il: lun 7 giu 2010, 9:25
Località: Verona

Re: MIB

Messaggio da Vas0sky » mer 26 set 2012, 20:48

allora credo che siano proprio 26
991

"L'ha vinto dopo mesi e mesi di tentativi"



"If we burn, you burn with us."

Avatar utente
TheFactor82
Amministratore
Messaggi: 7987
Iscritto il: gio 4 mag 2006, 21:26
Località: Torino
Contatta:

Re: MIB

Messaggio da TheFactor82 » gio 27 set 2012, 9:28

Dunque, prima di sparare dei numeri, così, un po' a casaccio, bisogna magari prima fare qualche ricerca.
Da quel che si discute qui, e le informazioni che ho scritto le ho prese dall'Orp, e non da Yahoo Answers, i fogli texture delle piste dovrebbero essere 10.
Questo perchè come giustamente dici tu Link, Revolt usa le lettere per i fogli texture.
Ora, le lettere sono 26. I giocatori massimi su una pista possono essere 12 (12 auto sono 12 fogli texture).
26-12 = 14.
I fogli FX che carica Revolt, secondo quanto detto dall'Orp, sono 4. (Ma nella cartella GFX i file chiamati FXPAGE sono solo 3). Se è vero quello che dice l'Orp, 14-4 = 10, che sono i fogli texture disponibili per la pista. Cioè dalla A alla J.
Questo quindi non mi fa capire come una pista come SM2 possa avere 11 fogli texture (fino alla K).
Risolto questo mistero dovresti avere il limite giusto di fogli texture per la pista.
La cosa migliore che puoi fare, a mio avviso, è chiedere a Huki e Jigebren, per avere una risposta corretta. :-)
My Gp's:
10 Settembre 2000: Monza - ITA (F1)
24-25 Aprile 2004: Imola - RSM (F1)
07 Ottobre 2007: Monza - ITA (WTCC)
31 Agosto 2008: Misano - ITA (MOTOGP/250/125)
05-07 Settembre 2008: Spa Francorchamps - BEL (F1)
20-22 Luglio 2012: Hockenheimring - GER (F1)
07 Settembre 2014: Monza - ITA (F1)
14 Aprile 2018: Roma - ITA (FE)

My ARM Card

Avatar utente
Vas0sky
Utente
Messaggi: 1856
Iscritto il: lun 7 giu 2010, 9:25
Località: Verona

Re: MIB

Messaggio da Vas0sky » gio 27 set 2012, 14:34

ci avevo pensato anche io che i fogli fossero solo 10 (e quindi la k non so cosa centri) ma magari sm2 li sfrutta diversamente (o magari va a prendere il foglio riservato all'hud che non viene utilizzato, dato che i bmp dell'hud sono 3 e non 4)... quindi non so... dovremmo provare ad aggiungere altri fogli di textures a sm2 per vedere il limite (che so, magari si modifica il file .w o il file .npc non mi ricordo e aggiungere un bmp per l'aggiunta del file) e vedere che succede con più bmp per la pista.... ho sparato un numero a caso, ma potrebbe essere che quando ci sono 26 bmp per la pista il resto viene tutto senza textures, oppure i fogli in più non vengono contati... chi lo sa? bisogna provare, e io un programma di grafica 3d non so usarlo, nè un mapper per auto e piste... e non sono nemmeno un esperto quindi potrei anche sparare stupidate una dietro l'altra
991

"L'ha vinto dopo mesi e mesi di tentativi"



"If we burn, you burn with us."

Linkinf22
Messaggi: 1144
Iscritto il: sab 25 ago 2007, 19:07

Re: MIB

Messaggio da Linkinf22 » dom 7 ott 2012, 22:44

Per quanto riguarda le lettere delle textures ho lasciato perdere per ora, verificando la presenza di texture fino alla Z. Magari mi informerò più avanti quando dovrò avere a che fare con la realizzazione di una pista anziché la sola visualizzazione (quindi quando starò lavorando al MIB vero e proprio).

Sono andato avanti, caricando e visualizzando gli AI Nodes:
SpoilerMostra
Immagine

Il codice sta diventando un po' un casino. Ho fatto bene a fare un progetto di prova prima di cominciare il MIB.
Ai creatori di piste ed auto potrebbe interessare il progetto MIB, c'è il topic nella sezione "Sviluppo" del forum.


Avatar utente
Vas0sky
Utente
Messaggi: 1856
Iscritto il: lun 7 giu 2010, 9:25
Località: Verona

Re: MIB

Messaggio da Vas0sky » mar 9 ott 2012, 14:14

perchè son tutti rossi? però è ottimo, visto che li visualizza... arriverai a visualizzare tutto?
991

"L'ha vinto dopo mesi e mesi di tentativi"



"If we burn, you burn with us."

Linkinf22
Messaggi: 1144
Iscritto il: sab 25 ago 2007, 19:07

Re: MIB

Messaggio da Linkinf22 » mar 9 ott 2012, 18:20

Perché per il modo in cui è fatto il codice mi diventa un po' un casino farli verdi e rossi.
Avrei dovuto modificare un sacco di codice solo per farli nei due colori, ma siccome dovrei aver capito (a livello di codice) quali sono quelli verdi e quali quelli rossi per ora lascio perdere e ci penserò quando starò facendo il MIB (quindi quando avrò pensato a come strutturare il codice).

In realtà ho appena pensato a un trucchetto che potrei provare a fare (e che magari se non fa calare di molto le prestazioni, ma non dovrebbe, potrei usarlo anche nel MIB in quanto mi sembra una buona soluzione).
Provo a farlo per vedere cosa mi esce, ma non so se posterò un altro screen solo per una piccola modifica. Potrei magari sostituire lo screen precedente :dubbi:
ciccio ha scritto:arriverai a visualizzare tutto?
Speriamo di si, così posso procedere al MIB :-)
Ultima modifica di Linkinf22 il mar 9 ott 2012, 18:23, modificato 3 volte in totale.
Ai creatori di piste ed auto potrebbe interessare il progetto MIB, c'è il topic nella sezione "Sviluppo" del forum.


Avatar utente
Vas0sky
Utente
Messaggi: 1856
Iscritto il: lun 7 giu 2010, 9:25
Località: Verona

Re: MIB

Messaggio da Vas0sky » mar 9 ott 2012, 19:09

non vedo l'ora :sbav:
991

"L'ha vinto dopo mesi e mesi di tentativi"



"If we burn, you burn with us."

Linkinf22
Messaggi: 1144
Iscritto il: sab 25 ago 2007, 19:07

Re: MIB

Messaggio da Linkinf22 » mar 9 ott 2012, 19:30

Niente, quel trucchetto (seppur fattibile), non vale la pena farlo: Dovrei duplicare il vertex buffer solo per cambiare il colore.
Quando starò facendo il MIB mi organizzerò in "più shader" in modo da dover passare solo un valore allo shader degli AI Nodes (se è verde o rosso). Questo mi consentirà di risparmiare memoria nel Vertex Buffer e di risparmiare la quantità di informazioni da passare al rendering.

In quel modo potrò passare una sola volta i vertici ed una sola volta l' informazione su quale colore usare, disegnare tutti gli AI Nodes di quel colore, cambiare l' informazione su quale colore usare e disegnare tutti gli AI Nodes di quest'altro colore. Inoltre il vertex shader ed il pixel shader avranno meno istruzioni.
Infatti ora, per il fatto che il codice è organizzato male, sto usando per gli AI Nodes lo stesso shader del "level", quindi tipo c'è anche il codice per le texture (seppure gli AI Nodes non abbiano texture) e altre informazioni passate che nel caso degli AI Nodes non servono a nulla.
Ai creatori di piste ed auto potrebbe interessare il progetto MIB, c'è il topic nella sezione "Sviluppo" del forum.


Linkinf22
Messaggi: 1144
Iscritto il: sab 25 ago 2007, 19:07

Re: MIB

Messaggio da Linkinf22 » dom 14 ott 2012, 0:38

Questo Sabato sera sono rimasto a casa perché già i miei amici non avevano organizzato nulla ed inoltre è pure arrivato un forte temporale.

Essendo a casa ad annoiarmi mi sono messo a continuare il Track Viewer.
Prima di stasera, dall' ultimo aggiornamento, ho aggiunto due particolari agli AI Nodes:

- Anche se lo scorso post avevo detto che non lo avrei fatto, ho separato gli AI Nodes nei due colori. Ovviamente l' ho fatto con il metodo che avevo detto, questo quindi ha implicato una duplicazione di Vertex Buffer ed Index Buffer della sfera. Siccome comunque si tratta solo di un programma di prova ho deciso di non curarmene.

- Le sfere degli AI Nodes della partenza sono 3 volte più grandi.

Dopodiché mi sono messo a lavorare ai POS Nodes, che sono ciò che ho completato stasera anche se con alcune cose tralasciate.
Infatti in Revolt (cosa che mi ha lasciato molto perplesso) non ho trovato una minima traccia dei POS Nodes. Sembra quasi che Revolt non lo carichi nemmeno il file dei POS Nodes :dubbi:
L' altro ieri ho passato un bel po' di tempo a cercare di capire quando dove e come Revolt carica i file dei POS Nodes, senza alcun risultato. Ho provato anche a caricare il file un po' a tentativi cercando di indovinare come fosse fatto, ovviamente senza alcun risultato.
Finchè stasera ho deciso di aprire i file .PAN di TITH1 e Supermarket 2 con un editor esadecimale. Inizialmente ci speravo poco di riuscire a capirci qualcosa, ma dopo un bel po' di osservazione e perplessità varie sono riuscito a vedere la certa ripetitività delle informazioni che mi ha permesso di capire come erano suddivise le varie informazioni.
Devo ringraziare soprattutto ciò che mi lascia più perplesso di tutta la struttura del file: 12 byte che ripetono sempre il valore massimo (FF in esadecimale).
Nei file .PAN infatti ci sono una quantità più grande di informazioni che precedono questi 12 byte, poi questi famosi 12 byte e poi 4 byte, poi ancora questi 12 byte e poi di nuovo la quantità più grande di informazioni.
Non sono riuscito a capire se questi 12 byte servono veramente a qualcosa (magari sono valori booleani che indicano qualche proprietà dei POS Nodes) o se sono solo messi lì come "suddivisori".
Della quantità più grande di informazioni ovviamente mi è stato facile capire che (essendo 20 byte) si trattesse delle coordinate dei POS Nodes (che sono 12 byte), altri 4 byte sono numeri che stanno tra zero ed il numero di POS Nodes che ci sono nella pista. E siamo a 16 byte. Restano altri 4 byte che mi restano un altro mistero, sono numeri abbastanza alti che non ho capito a cosa possano servire.
I 4 byte che stanno tra i 12 byte a valore FF e gli altri 12 byte a valore FF sono ancora numeri compresi tra zero ed il numero di POS Nodes che ci sono nella pista.
Quindi, le coordinate dei POS Nodes le ho trovate, gli 8 byte che indicano numeri compresi tra zero e la quantità di POS Nodes della pista penso indichino 4 byte il numero che identifica il POS Nodes mentre gli altri 4 byte potrebbero essere il numero che identifica il POS Nodes al quale il POS Nodes che si sta "descrivendo" al momento è collegato.

Di misteriosi restano quei 24 byte tutti a valore FF e quei 4 byte che hanno valore abbastanza alto (ho pensato che potrebbero indicare una distanza, tipo la distanza dal primo POS Nodes o dal POS Nodes precedente o successivo, o la distanza restante per completare il giro, bho).

Magari per chi non sa nulla di programmazione e di queste cose gli ho solo fatto confusione, ma per chi ne sa qualcosina che è abbastanza interessato spero si capisca qualcosa.

Insomma, alla fine sono riuscito a tirar fuori anche le coordinate dei POS Nodes (per identificarli, li ho fatti con sfere ben 10 volte più grandi rispetto alle sfere degli AI Nodes):
SpoilerMostra
Immagine
Ai creatori di piste ed auto potrebbe interessare il progetto MIB, c'è il topic nella sezione "Sviluppo" del forum.


Maximvs
Messaggi: 402
Iscritto il: sab 14 giu 2008, 11:27

Re: MIB

Messaggio da Maximvs » dom 14 ott 2012, 12:43

link Ho cercato di capire cosa stavi dicendo, a riguardo del file .pan, ho cercato nel file .exe dove veniva usato è trovandolo ho capito che serve per sapere anche la posizione attuale durante una gara il numero di giri percorsi nella gara è le informazioni tipo la lunghezza della pista sono contenute al suo interno se noti nel file di ogni pista c'è un numero che va a incrementarsi dopo la dozzina di bytes messi a 255 partendo da 1

Linkinf22
Messaggi: 1144
Iscritto il: sab 25 ago 2007, 19:07

Re: MIB

Messaggio da Linkinf22 » dom 14 ott 2012, 13:59

Queste informazioni già le sapevo Maxi.
Il numero che si incrementa credo sia il numero che identifica il POS Node, ma non ne sono certo.

Ciò che a me interesserebbe sapere sono se i 12 byte impostati a 255 indicano qualcosa o se sono solo dei "divisori" (ma mi sembra un po' esagerato sprecare ben 24 byte per ogni POS Node contenuto nel file solo per un "divisore").
Stavo pensando che siccome un POS Node può essere collegato a più POS Node (quindi non obbligatoriamente ad uno solo), magari quei 12 byte indicano appunto a quanti POS Node quel POS Node è collegato (e magari il limite di POS Node che si possono collegare ad un POS Node è proprio 12).
In effetti se non ricordo male (ma dovrei riguardare) quei 24 byte in TITH 1 non erano così ripetitivi come in Supermarket 2 ed in TITH 1, infatti c'è la strada secondaria in cui ci sono alcuni POS Nodes ed il POS Node che precede la strada secondaria e quello che la sussegue sono collegari a 2 POS Node, non a 1.
Dovrei riguardarlo meglio per vedere se i 24 byte che in supermarket 2 sono tutti impostati a FF in TITH 1 magari variano perché indicano proprio se il POS Node è collegato a più POS Nodes.

Inoltre ci sono altri 4 byte misteriosi. Stanno prima dei 12 byte che indicano le coordinate del POS Node, non sono riuscito a capire cosa indica il loro valore (ho pensato a qualche distanza).

Se guardando l' EXE di Revolt riesci a scoprire cosa sono quei 24 byte tutti impostati ad FF (nel caso di Supermarket 2) e cosa indicano quei 4 byte che precedono le coordinate di ogni POS Node te ne sarei grato.
Ultima modifica di Linkinf22 il dom 14 ott 2012, 14:04, modificato 1 volta in totale.
Ai creatori di piste ed auto potrebbe interessare il progetto MIB, c'è il topic nella sezione "Sviluppo" del forum.


Avatar utente
Vas0sky
Utente
Messaggi: 1856
Iscritto il: lun 7 giu 2010, 9:25
Località: Verona

Re: MIB

Messaggio da Vas0sky » dom 14 ott 2012, 15:15

Io non so nulla di programmazione, ma secondo me quei 4 byte servono per le coordinate del collegamenti... Invece per scoprire i byte a valore ff basterebbe creare due percorsi di pos nodes, uno senza doppi collegamenti e l'altro con... Semplice no? Anche perchê si potrebbero vedere le differenze tra due percorsi simili
991

"L'ha vinto dopo mesi e mesi di tentativi"



"If we burn, you burn with us."

Maximvs
Messaggi: 402
Iscritto il: sab 14 giu 2008, 11:27

Re: MIB

Messaggio da Maximvs » dom 14 ott 2012, 17:31

Allora per me i dodici byte posti a FF sono riferimenti non usati, i primi se spostati creano dei salti che il gioco nel caricamento della pista non trova nel file .hul dove c'è la macchina ho notato un'altra cosa che lavorano a coppie di 8 ossia:
FFFF FFFF anche perchè ad esempio la distanza espressa in metri della pista che uno sceglie, in questo caso market2 è composta da:
24C3 6B47 che sarebbero 301 metri

Linkinf22
Messaggi: 1144
Iscritto il: sab 25 ago 2007, 19:07

Re: MIB

Messaggio da Linkinf22 » dom 14 ott 2012, 18:20

ciccio ha scritto:secondo me quei 4 byte servono per le coordinate del collegamenti
Che quei 4 byte servano per le coordinate dei collegamenti non ha senso, se per coordinate intendi l' X Y Z, in quanto per delle coordinate servono 12 byte (e poi sarebbe assurdo rimettere le coordinate di un POS Node che esiste già, semmai metti l' ID). Inoltre il valore che rappresentano è sempre alto, quindi non potrebbe nemmeno essere l' ID di un altro POS Node a cui è collegato. Come già detto, potrebbero rappresentare delle distanze.

Inoltre se non ricordo male mi sembra che ci siano già due "4 byte" con valori che stanno tra gli ID dei POS Node, quindi mettendo che uno è l' ID del POS Node stesso l' altro probabilmente è l' ID del POS Node a cui è collegato (anche se resta il mistero del caso di un POS Node collegato a più POS Nodes).

ciccio ha scritto:Invece per scoprire i byte a valore ff basterebbe creare due percorsi di pos nodes, uno senza doppi collegamenti e l'altro con
Questa può essere una bella idea.
Magari modificherò i POS Nodes di una pista: Cancello tutti i POS Nodes della pista, creo 3 POS Nodes collegati tra di loro (a triangolo), salvo il file, lo copio da un' altra parte, riapro il MIG su quella pista, modifico i POS Nodes mettendone un quarto e li collego tra di loro, collegandone uno a due POS Nodes e salvo. Dopodiché aprirò i due file con l' editor esadecimale e vedrò le differenze.

Però lo farò un altro giorno.
Maximvs ha scritto: i primi se spostati creano dei salti che il gioco nel caricamento ...
Con "i primi" intendi i 4 byte che stanno prima delle coordinate?
Maximvs ha scritto:creano dei salti che il gioco nel caricamento della pista non trova nel file .hul
Cosa veramente strana, cosa hanno a che fare le collisioni con delle robe che determinano le distanze? (i file .hull contengono le informazioni per le collisioni delle auto giusto?)
Maximvs ha scritto:lavorano a coppie di 8 ossia:
FFFF FFFF
Quindi a coppie di 4 byte?
Maximvs ha scritto:anche perchè ad esempio la distanza espressa in metri della pista che uno sceglie, in questo caso market2 è composta da:
24C3 6B47 che sarebbero 301 metri
Ma tu hai trovato 24C3 6B47 nel file .PAN di supermarket 2?

Comunque in quanto alla lunghezza della pista non so se l' informazione è scritta nel file dei POS Nodes, in quanto l' ultima informazione del file degli AI Nodes (gli ultimi 4 byte) contengono un valore che combacia con l' ultima scritta che appare quando si usa il MIG con selezionati gli AI Nodes: "Trackdist: 148003" nel caso di Toys In The Hood 1.
Questo valore non combacia con la lunghezza della pista che appare quanto si seleziona la pista (747 metri per TITH 1), ma potrebbe essere un valore che poi viene "scalato" in metri.
Ai creatori di piste ed auto potrebbe interessare il progetto MIB, c'è il topic nella sezione "Sviluppo" del forum.


Maximvs
Messaggi: 402
Iscritto il: sab 14 giu 2008, 11:27

Re: MIB

Messaggio da Maximvs » dom 14 ott 2012, 19:41

Si linkinf22 la lunghezza della pista è contenuta nel file .pan, come è contenuta la distanza di ogni macchina sembra una cosa strana ma ho modificato il file .exe e ho guardato la risposta, succedono questo genere di cose anche io credo come te che siano delle distanze ritornando a quei famosi Bytes...
il primo gruppo di bytes posti a FF se modificati creano un collasso nel caricamento del file .hul delle auto.
Mentre per rispondere a una delle tue domande si i metri della pista supermarket 2 l'ho trovato nel file .pan
Maximvs ha scritto:
lavorano a coppie di 8 ossia:
FFFF FFFF

Quindi a coppie di 4 byte?
Si

Rispondi

Chi c’è in linea

Visitano il forum: Nessuno e 6 ospiti