Outpost 2 ફાઈલ ફોર્મેટ્સ · bei.pm

Outpost 2 દ્વારા ઉપયોગમાં લેવાતા ડેટા ફોર્મેટ્સનું ઢાંકણ JFIF / PNG ની સમાન રચના ધરાવે છે - અલગ અલગ ડેટા બ્લોકોમાં હંમેશા 8 બાઇટ હેડર હોય છે. આથી, હું તે વ્યક્તિગત હેડરોને સંબંધિત વિશિષ્ટ સ્થળોએ મર્યાદિત રાખું છું અને ત્યાં ફક્ત વિલંબોને જ દસ્તાવેજીકરણ કરું છું.

ફોર્મેટ હંમેશા નીચે મુજબ છે; વાસ્તવિક ઉપયોગી ડેટા તેમાં એમ્બેડેડ છે:

વાર્તાઓ એ રમત માટેનો ડેટા કન્ટેનર છે, જે ટારબોલ જેવા આર્કાઇવ ફોર્મેટની જેમ છે. ઓટપોસ્ટ 2 માં આ ફોર્મેટમાં ફક્ત ફાઇલો જ છે - ફોલ્ડર નથી. હોઈ શકે છે કે આને સંબંધીત ફાઇલના નામો દ્વારા નકલ કરી શકાય.

એક વોલ્યુમમાં વોલ્યુમ હેડર અને અનેક વોલ્યુમ બ્લોક્સ હોય છે, જે ચોક્કસ ફાઇલોને અનુરૂપ હોય છે.

"વોલ્યુમ" એ રમતના ડિરેક્ટરીમાં 'vol' એક્સ્ટેન્શનવાળી ફાઇલો છે.

વોલ્યુમ હેડરમાં કોઈપણ ઉપયોગી ડેટા નથી.
તે ફક્ત કન્ટેનર તરીકે સેવા આપે છે.

વોલ્યુમ હેડરમાં પહેલું ડેટા વોલ્યુમ સ્ટ્રિંગ્સ હોવું જોઈએ; ત્યારબાદ વોલ્યુમ માહિતી આવે છે.

વોલ્યુમ સ્ટ્રિંગ્સ ફાઇલોના નામોની એક યાદી છે, જે વોલ્યુમના અંદરના ભાગમાં સમાવિષ્ટ છે.

વોલ્યુમ માહિતી ફાઇલો વિશે વધુ વિગતવાર માહિતી પ્રદાન કરે છે. આ કેટલીક રીતે FAT ડિરેક્ટોરી એન્ટ્રીની જેમ હોય છે (FAT = ફાઇલ અલૉકેશન ટેબલ)

ફાઇલોની સંખ્યા બ્લોક કદને ડિરેક્ટોરી એન્ટ્રીઓની લાંબાઈ - 14 બાઇટ દ્વારા વહેંચી શકાય છે.

વિશિષ્ટ ડિરેક્ટોરી એન્ટ્રીઓની રચના નીચે મુજબ છે:

વોલ્યુમ બ્લોક એક કન્ટેનર છે, જે ફાઇલોને સ્થાન આપે છે. તે ફક્ત એક જ વખત - બ્લોક ફોર્મેટના કારણે - ફાઇલના કદની પુનરાવર્તિત માહિતી ધરાવે છે અને પછી સીધા ઉપયોગી ડેટા આવે છે.

ટાઇલ્સ એ એક Outpost-2-વિશિષ્ટ બિટમેપ ગ્રાફિક ફોર્મેટ છે. તે 13 ટાઇલસેટ્સમાં વિસ્તૃત થાય છે, જેને "વેલ્સ" કહેવામાં આવે છે (well0000.bmp થી well0012.bmp), જે maps.vol નામના વોલ્યુમમાં જોવા મળે છે.

તેમાં ટાઇલ્સેટ્સ / વેલ્સમાં નીચેના સામગ્રી સામેલ છે:

એક યોગ્ય અમલ માટે, ટાઇલ્સને અગાઉથી રેન્ડર કરવાનો અને તેમને કેચ કરવાનો સલાહ નથી, કારણ કે દિવસ/રાત ચક્ર માટેના ડેટાને હજુ પણ સંપાદિત કરવું પડશે - અને આ માટે ઘણી બધી માહિતી એકઠી થશે.

ટાઇલ્સ 8bpp ગ્રાફિક્સ છે જેમની ઇન્ડેક્સ કરેલી પાલેટ છે અને જે 32x32 પિક્સલના રિઝોલ્યુશનમાં છે, જે એકબીજા સાથે ક્રમમાં છે. આ રીતે બનાવવામાં આવેલા ટાઇલસેટમાં વધુથી વધુ

મુખ્ય કન્ટેનર 2 સેક્ટન્સમાંથી બનેલું છે: head અને data.

આ માહિતી પછી, એક માનક RIFF ફોર્મેટમાં હાજર પેલેટ ફાઇલ પણ ઉપલબ્ધ છે. ચોક્કસ સ્પષ્ટીકરણ - કારણ કે પેલેટો અન્ય સ્થળોએ પણ દેખાય છે - તે પેલેટો હેઠળ મળશે.

અંતે સફેદ પિક્સેલ ડેટા છે, જે ડાબી-ઉપરથી પંક્તિવાર હક તરફ જતાં જતાં નીચે જતો છે.
સામાન્ય રીતે 8bpp-બિટમેપ્સમાં મળતી ગ્રાફિક્સનો ડેટા મૂલ્ય રંગ પેલેટમાં રંગના ઇન્ડેક્સને દર્શાવે છે.

આ રમત એન્જિન ટાઇલ્સને *શાયદ* માંગ મુજબ કેળવે છે.
આ, 32 અલગ અલગ ટાઇલ્સની અંકગણતરીને કારણે દિવસ-રાત ચક્રને કારણે છે. આ દરમિયાન, સ્પષ્ટ રીતે તેજસ્વિતાના મૂલ્યમાંથી 'કેટલાક' ઘટાડવામાં આવે છે. ચોક્કસ મૂલ્યો હજુ સુધી જાણી શકાયા નથી, હું આ ગણતરીની આધારભૂત પર કાર્ય કરી રહ્યો છું.

v *= (daylight / 48) + 0.25;

પિક્સલનાં HSV ડેટા સાથે, જ્યાં daylight 0-31 નો મૂલ્ય છે અને v 0-1 વચ્ચેનો મૂલ્ય છે. ત્યારે ધ્યાનમાં લેવા જેવું છે કે નકશા પર બાજુએ 16 ટાઇલ્સનું મર્યાદા છે (જે અદૃશ્ય યુનિટો બનાવવા માટે છે).

તે ઉપરાંત, દિવસ-રાત ચક્ર દરેક રમત ચક્રમાં માત્ર એક કૉલમને અપડેટ કરે છે.
ઝડપી દિવસ-રાત ચક્ર એવું દેખાય છે:

PRT નો અર્થ ચોક્કસ કયો છે મને ખબર નથી; ઉદાહરણ તરીકે 'પેલેટ અને સ્ત્રોત કોષ્ટક' હોઈ શકે છે - કારણ કે આ ફાઇલ - જે op2_art.prt તરીકે મળતી છે maps.vol માં - આવી જ છે, અથવા આ કાર્યને સારી રીતે વર્ણવશે.

આ ફાઇલમાં પેલેટની યાદી, તમામ ઉપયોગમાં લેવાયેલા બિટમેપ્સ અંગેની કોષ્ટક, તમામ એનિમેશન વ્યાખ્યાઓ અને કેટલીક અજ્ઞાત માહિતીનો સામેલ છે. તે અત્યાર સુધીના કન્ટેનર ફોર્મેટને ઢીલા રીતે અનુસરે છે, કારણ કે તમામ ડેટા રેકોર્ડ આ સ્કીમાનું પાલન નથી કરતા.

CPAL વિભાગ (શાયદ પેલેટ કન્ટેનર માટે) ફક્ત પેલેટ ડેટાને આવરી લે છે, જે બતાવે છે કે સામાન્ય રીતે 1052 બાઇટના 8-બિટ પેલેટ્સમાં કેટલી છે.

1052-બાઇટની આ માહિતી બાંધકામ તરીકે માન્ય નથી, કારણ કે પેલેટ ફોર્મેટમાં સંભવિત રીતે અલગ અલગ પેલેટ કદ હોઈ શકે છે. આ ફક્ત તે ડેટા સંગ્રહ માટે છે, જે આઉટપોસ્ટ 2 સાથે રજૂ કરવામાં આવે છે.

પેલેટની યાદી પછી તરત અને કોઈ શરૂઆતની હેડર વગર, બિટમેપ્સની યાદી આવે છે; ત્યારબાદ એનિમેશનની યાદીઓ તરત આગળ આવે છે.
બન્નેને દરેકમાં uint(32) (અથવા ફરી uint24+uint8 ફ્લેગ્સ?) દ્વારા શરૂ કરવામાં આવે છે, જેમાં રેકોર્ડની સંખ્યા હોય છે.

પેલેટ માહિતી વાંચવું ખૂબ જ આરસ છે.
તેમાં દરેકમાં એક હેડર અને એક ડેટા સેગમેન્ટ હોય છે.

ડેટા વિભાગમાં અલગ-અલગ પેલેટ એન્ટ્રીઓ સમાવિષ્ટ છે. પેલેટ એન્ટ્રીઓની સંખ્યા બ્લોકની લંબાઈ / 4 પરથી મળે છે.

અલગ-અલગ એન્ટ્રીઓના માટે નીચે મુજબનો સરળ બંધારણ છે;

પાલેટ્સ વિશે વધુ કહી શકાય છે કે, એનિમેશન્સ માટે ઉપયોગમાં લેવાતા પાલેટ્સ માટે નીચેની નિયમો લાગુ છે:

• પ્રથમ રંગ હંમેશા પારદર્શક છે, ત્યાં જે પણ મૂલ્ય આપવામાં આવ્યું છે તે બિનમહત્વપૂર્ણ છે.
• પાલેટ્સ 1-8 માં 1-24 ના પાલેટના પ્રવેશોને ખેલાડીના રંગ તરીકે માનવામાં આવે છે.
  રંગો ખેલાડી 1 થી બહાર ક્યાંથી આવે છે તે મને સ્પષ્ટ નથી.
  હું અનુમાન કરું છું કે બાકીના રંગો હાર્ડકોડેડ છે.

PRT ફાઈલની આ ડેટા રચના દર્શાવે છે કે સ્પ્રાઇટ્સ માટે વપરાતા બિટમેપ્સ કેવી રીતે રચાયેલ છે. આ બિટમેપ્સ એક જ ઘટક તરીકે કાર્ય કરે છે, જેમાંથી ઘણા એક સ્પ્રાઇટના એનિમેશન ફ્રેમમાં જોડાયેલા છે.

સ્પષ્ટ છબી ડેટા તે સામે op2_art.BMPમાં રમતના ડિરેક્ટરીમાં છુપાયેલા છે.
આ બિટમેપ ફાઇલમાં એક (મુખ્યત્વે યોગ્ય) RIFF-બિટમેપ હેડર કેમ છે, તે સ્પષ્ટ નથી. શક્યતઃ આઉટપોસ્ટ 2 ગ્રાફિક્સ લોડ કરવા માટે સિસ્ટમ-API નો ઉપયોગ કરે છે, જેમાં આ હેડરને કાળજીપૂર્વક અપનાવીને સંબંધિત, બદલાતી ફિલ્ડને ઓવરરાઈટ કરવામાં આવે છે.

PIXEL ડેટા BMP ફાઈલમાં સ્થાને છે ઓફ્સેટ + uint32-ઓફ્સેટ, જે BMP ફાઈલમાં સરનામા 0x000A પર જોવા મળે છે (RIFF-બિટમેપ ડેટા ઓફ્સેટ), અને ફરીથી ઉપરથી ખાબકીને ડાબી તરફ અને જમણી તરફની કતારમાં છે.

મોનોક્રોમ 1bpp ગ્રાફિક્સ એવી રીતે કળા કરી શકાય છે કે રંગ 0 પૂર્ણ પારદર્શક છે, તેમજ રંગ 1 અર્ધપારદર્શક કાળી/ગ્રે છે, કારણ કે મોનોક્રોમ ગ્રાફિક્સ સામાન્ય રીતે વાહન અને ઇમારતોના છાયાઓ માટે એનિમેશનમાં વપરાય છે.

તેથી ઘણા ગ્રાફિક્સને એકત્રિત કરી શકાય છે.

હવે અમે આઉટપોસ્ટ 2 ડેટા ફોર્મેટની શિસ્તોના કિંગ ક્લાસમાં આવે છે:
એનિમેશન્સ.

એનિમેશન સૂચિઓ એક વૈશ્વિક હેડર સાથે શરૂ થાય છે, જે મુખ્યત્વે ડેટા માન્યતા માટે સેવા આપે છે. તેથી ચોક્કસ એનિમેશન વ્યાખ્યાઓ આવે છે, જે 3 સ્તરે વહેંચાય છે:

1. એનિમેશન
   એક એનિમેશન સૌથી ઉંચી આવૃત્તિ છે; તે એક એકક, એક ઇમારત અથવા 'પાર્ટિકલ એનિમેશન' (કમેટ ટકરાવ, વાતાવરણ, વિસ્ફોટ) ની એક ચોક્કસ આઉટસેટમાં એનિમેશનને દર્શાવે છે.
2. ફ્રેમ
   એક ફ્રેમ એ એનિમેશનમાં એક જ છબી છે. એક એનિમેશનમાં એક અથવા વધુ ફ્રેમ્સ હોઈ શકે છે.
3. સબફ્રેમ
   એક સબફ્રેમ એ માહિતી છે કે એક ચોક્કસ બિટમેપને ચોક્કસ માપદંડો હેઠળ ફ્રેમના ચોક્કસ સ્થાન પર ચિતરવુ પડશે. એક ફ્રેમમાં એક અથવા વધુ સબફ્રેમ્સ હોઈ શકે છે.

તે પછી સીધા જ વિવિધ એનિમેશન વ્યાખ્યાઓ આવે છે.

ઉચ્ચતમ સ્તરની માહિતી, જે એનિમેશનની છે, મુખ્યત્વે વ્યવસ્થાપન ડેટા છે - બાઉન્ડિંગબોક્સ તે વાહન/ભવનની નિશાનની અવ્યાખ્યા દર્શાવે છે, જ્યારે તે પસંદ કરવામાં આવે છે અને સાથે સાથે સૂચવે છે કે કયો વિસ્તાર ક્લિક કરવો જોઈએ.

ઓફસેટ મુખ્યત્વે "ઝીરો પોઈન્ટ"ને નિર્ધારિત કરે છે; તે બિંદુ, જે રમતની આંતરિક અવ્યાખ્યાઓમાં ઉમેરવામાં કિંવાતા જમણાં ઉપાડવો જોઈએ. ગણિતીય રીતે કહી શકાય છે: આ ઓફસેટ અહીં અવ્યાખ્યા મૂળને દર્શાવે છે.

વિન્ડોઝમાં, જેમ કે ઓફસેટમાં, દરેક (પ્રત્યેક વિન્ડો માટે) 4 uint(32)-મૂલ્યો છે, જેથી એક ક્ષેત્ર દર્શાવવામાં આવે છે, જે ચોક્કસ સબફ્રેમ્સ માટે ઉપયોગી છે. વિન્ડોઝના બહાર, જો બિટમેપ માટે યોગ્ય હોય, ત્યાં દ્રષ્ટિ આપવી ન જોઈએ.

આથી, હવે આપણે એકલ ફ્રેમ્સને તેમજ સંપૂર્ણ એનિમેશન્સને યોગ્ય રીતે એકત્રિત કરી શકીએ છીએ, અહીં એક જટિલ એનિમેશન, જેનું ઇન્ડેક્સ 500 છે, તેનું ઉદાહરણ દર્શાવ્યું છે

એનિમેશન 500 દર્શાવે છે કે કેવી રીતે એક પ્લાયમાઉથ પરિવહન, જે સામાન્ય ખનિજથી ભરેલું છે, ખાલી કરવામાં આવે છે. આ એક જ قليلة એનિમેશનમાંના છે, જે વિન્ડો ફંક્શનાલિટીની ઉપયોગ કરે છે.

અને આ રીતે સંપૂર્ણ એનિમેશનને જોડવામાં આવી શકે છે.
દુઃખદ રીતે, ઉપરની લોડિંગ હૂક સાથે હજુ એક સમસ્યા છે, કારણ કે અહીં ગ્રાફિક પ્રકારની માહિતીમાં સંબંધિત બિટ સેટ નથી.

અહીં રમણीय રીતે એનિમેટેડ કેટલાક વધુ સ્પ્રાઇટ્સ છે:

હવે રમતનું યુઝર-ઇન્ટરફેસ બાકી છે, જે બ્રશ્ડ મેટલ લુકમાં છે.

પણ અહીં પણ સ્પષ્ટ છે કે Dynamixએ આચરણને નવી રીતે શોધવું પડ્યું નથી; અહીં ફક્ત Windows દ્વારા પૂરી પાડવામાં આવતી User32 અને GDI32 API નો ઉપયોગ કરવામાં આવ્યો નથી - ખાસ કરીને User32 તરફથી સંસાધન વ્યવસ્થાપનનો ઉપયોગ કરવામાં આવ્યો છે.

આને ઉદાહરણ તરીકે Angus Johnson દ્વારા ફ્રીવેર તરીકે વિકસિત Resource Hacker જેવી પ્રોગ્રામો દ્વારા કાઢી શકાય છે, અથવા - જો તમે Linux / Mac OS પર Wine નો ઉપયોગ કરવાથી કાંટો છો - તો icoutilsમાં સમાવિષ્ટ wrestool ની મદદથી કાઢી શકાય છે.