Outpost 2 ទម្រង់ឯកសារ · bei.pm

ទ្រង់ទ្រាយទិន្នន័យដែលប្រើប្រាស់ដោយ Outpost 2 មានរចនាប័ទ្មដូចជាទ្រង់ទ្រាយ JFIF / PNG - ប្លុកទិន្នន័យនីមួយៗមានក្បាល 8 បាយ។ ដូចនេះ ខ្ញុំក៏លែងចាំបាច់ឱ្យឯកសារមានក្បាលនីមួយៗនៅកន្លែងដែលពាក់ព័ន្ធ ហើយគ្រាន់តែឯកសារបញ្ហាប្រឈម។

ទ្រង់ទ្រាយគឺជាទ្រង់ទ្រាយដដែល; ទិន្នន័យដែលមានអត្ថប្រយោជន៍ត្រូវបានបញ្ចូលក្នុងនេះ។

វ៉ូល្យូម គឺជាកុងតឺនរស់សម្រាប់ទិន្នន័យសម្រាប់ហ្គេម ដែលមានគំនិតស្រដៀងនឹងទ្រង់ទ្រាយសារពើភ័ណ្ឌ ដូចជា Tarball។ យ៉ាងហោចណាស់ នៅក្នុង Outpost 2 ទ្រង់ទ្រាយនេះគ្រាន់តែស្គាល់ថា ជាឯកសារ - គ្មានថតឯកសារ។ អាចមានការសម្តែងថា អាចប្រែប្រួលឯកសារ ដោយប្រើឈ្មោះឯកសារដែលសមស្រប។

វ៉ូល្យូម ត្រូវបានកំណត់ពី Volume-Header និងវ៉ូល្យូមប្លុកច្រើនដែលត correspond នឹងឯកសារពិតប្រាកដ។

"វ៉ូល្យូម" គឺជាឯកសារដែលមានបញ្ចប់ 'vol' នៅក្នុងថតហ្គេម។

គេហៅថា Volume Header មិនមានទិន្នន័យប្រើប្រាស់នៅក្នុងខ្លួនវាទេ។
វាផ្តល់ជារង្វង់ប៉ុណ្ណោះ។

ជា​ទិន្នន័យដំបូងក្នុង Volume Header គួរត្រូវមាន Volume Strings; បន្ទាប់មកគឺជាព័ត៌មាន Volume។

Volume Strings គឺជាបញ្ជីនៃឈ្មោះឯកសារ ដែលមានក្នុង volume នេះ។

ព័ត៌មានបរិមាណនឹងផ្តល់ព័ត៌មានលម្អិតអំពីឯកសារនានា។ វាជារបៀបមួយនៃការចុះបញ្ជី FAT (FAT = តារាងចំណាត់ថ្នាក់ឯកសារ)។

ចំនួនឯកសារនឹងត្រូវបានគណនាដោយការបែងចែកទំហំប្លុកដោយប្រវែងនៃការចុះបញ្ជី - ១៤ បាយ។

ការចុះបញ្ជីនីមួយៗមានសំណុំពីរបៀបដូចតទៅ៖

ប្លុកប៉ុស្តិ៍មួយគឺជាកុងតែន័រ ដែលទទួលឯកសារ។ វាបានរួមបញ្ចូលទំហំឯកសារម្តងទៀត - ដោយសារតែកម្មវិធីប្លុក - យ៉ាងច្រើន ហើយបន្ទាប់មក នឹងមានទិន្នន័យប្រើប្រាស់ភ្លាមៗ។

ជាត្បូងនោះគឺជារូបភាព Bitmap ដែលមានលក្ខណៈពិសេសសម្រាប់ Outpost-2។ វាបន្តអំឡុង 13 Tilesets ឈ្មោះថា "wells" (well0000.bmp ដល់ well0012.bmp), ដែលស្ថិតនៅក្នុងបរិមាណ maps.vol។

ក្នុងនោះ Tilesets / Wells មានអ្វីខ្លះ:

វាជាការល្អមួយសម្រាប់ការអនុវត្តន៍ឲ្យបានត្រឹមត្រូវ គឺមិនគួរបង្ហាញ Tiles មុនដើម្បីកណ្តាលសម្រាប់ការផ្ទុក ក្រោយពេលដែលទិន្នន័យសម្រាប់វដ្តថ្ងៃ/យប់ត្រូវតែត្រូវបានកែសម្រួល - ហើយមានទិន្នន័យច្រើនណាស់នឹងកើតមាន។

Tile គឺជាគំនូរ 8bpp ដែលមានកណ្តាលពណ៌បញ្ជីក្នុងទំហំ 32x32 ភីកសែល ដែលត្រូវបានរៀបចំជាទូទៅ។ នៅក្នុង Tileset ដែលបានបង្កើតឡើង អាចមានច្រើនជាងនេះ

កុងតឺន័រ Haupt មានរាងកាយពី 2 ផ្នែក៖ head និង data។

បន្ទាប់ពីព័ត៌មានเหล่านี้ មានឯកសារពណ៌ដែលមានរូបរាងជា RIFF នៅក្នុងទ្រង់ទ្រាយស្តង់ដ៍។ ការបញ្ជាក់អំពីពណ៌នេះអាចរកឃើញបាន - ពីព្រោះពណ៌នឹងបង្ហាញនៅកន្លែងផ្សេងទៀត - នៅក្រោម ក្រុមពណ៌.

ចុងក្រោយនេះគឺជាព័ត៌មានពីពីកន្លែងដែលទិន្នន័យប៊ិចតមាននៅក្នុងទ្រង់ទ្រាយប្រព័ន្ធណែនាំពីខាងឆ្វេង-លើទៅខាងស្តាំ-ខាងក្រោម។
តម្លៃទិន្នន័យសម្រាប់គំនូសដែលជាទូទៅមានទ្រង់ទ្រាយ 8bpp-Bitmap នោះគឺស្មើនឹងសមាជិកនៃពណ៌ក្នុងក្រុមពណ៌។

ម៉ាស៊ីនលេងហ្គេមកំពុងគូសTiles ដោយ*ប្រហែល*តាមតម្រូវការ។
នេះហាក់ដូចជាអាស្រ័យលើវដ្តថ្ងៃ-យប់ ដែលមានការបំបែកជាប្រភេទ 32 រាងសម្រាប់Tiles មួយៗ។ នៅពេលនេះ មិនថាតើតម្លៃភ្លឺប្រាជ្ញាអង្កេត 'បន្តិច' ត្រូវបានដកចេញ។ តម្លៃពិតប្រាកដមិនអាចកំណត់បាននៅឡើយ ខ្ញុំកំពុងធ្វើការលើមូលដ្ឋានកំណត់តម្លៃ

v *= (daylight / 48) + 0.25;

ជាមួយទិន្នន័យHSV នៃPixel ខណៈដែល daylight ជាតម្លៃពី 0-31 និង v ជាតម្លៃពី 0-1។ ក្រៅពីនេះ ត្រូវគិតថានៅលើផែនទី មានដែនសំបូរដែលមាន 16 Tilesទៅឆ្វេង និងឆ្វេង (ដែលមានគោលបំណងសម្រាប់ការបង្កើតអង្គភាពក្នុងគោលដៅឥតមិនខាន)។

បន្ថែមពីនេះ វដ្តថ្ងៃ-យប់ត្រូវអាប់ដេតតែជួរដេកមួយនៃផែនទីសម្រាប់រាល់វគ្គហ្គេម។
វដ្តថ្ងៃ-យប់ដែលលឿនសូមមើលដូចខាងក្រោម៖

តើ PRT មានន័យដូចម្តេចពិតប្រាកដខ្ញុំមិនដឹងទេ; តែអាចនឹងមានន័យដូចជា 'Palette and Ressource Table' - ព្រោះឯកសារនេះ - ដែលអាចរកបានជា op2_art.prt ក្នុង maps.vol - គឺជាឯកសារដែលមានលក្ខណៈដូច្នេះ ឬវាអាចពិពណ៌នាអំពីមុខងារនេះបានយ៉ាងល្អ។

ឯកសារនេះមានបញ្ជីស្ពាននានា បញ្ជីស្ពានទាំងអស់ដែលបានប្រើប្រាស់ Bitmaps ទាំងអស់ ការកំណត់ត្រាអនីមេ이션 និងទិន្នន័យមិនស្គាល់មួយចំនួន។ វាបន្តហើយបន្តនឹងទម្រង់ខុងតេនឌេរ ដែលក៏មានស្រាយតិចតួច ដោយមិនទាន់មានទិន្នន័យទាំងអស់ដែលអនុវត្តតាមគំរូនេះ។

ផ្នែក CPAL (ដែលអាចមានន័យថា Paletten-Container) គ្រាន់តែបញ្ចូលទិន្នន័យស្ពាន តាមរយៈការបញ្ជាក់ពីចំនួនស្ពានដែលមាននៅក្នុងទម្រង់ 8-Bit ដែលធម្មតាមានទំហំ 1052 បាយ។

ការបញ្ជាក់ 1052 បាយនេះមិនត្រូវបានចាត់ទុកថាជាការកំណត់ទេ ព្រោះទម្រង់ស្ពានអាចមានទំហំស្ពាននានាដែលខុសគ្នា។ វាត្រូវបានអនុវត្តតែសំរាប់ទិន្នន័យដែលចេញផ្សាយជាមួយ Outpost 2 ប៉ុណ្ណោះ។

ក្រោយពីបញ្ជីស្ពាន គឺមានបញ្ជី Bitmaps ដែលតាមដានដោយគ្មានពាក្យដើម និងការបញ្ជីអនីមេ이션តាមបន្ទាប់។
ទាំងពីរនេះនឹងចាប់ផ្តើមជាមួយ uint(32) (ឬប៉ុន្តែ uint24+uint8 flags?) ដែលមានចំនួនកំណត់ត្រា។

ព័ត៌មានពីក្បាលគឺអានបានយ៉ាងងាយស្រួល។
វាមានទាំងមួយក្បាលនិងមួយផ្នែកទិន្នន័យ។

ផ្នែកទិន្នន័យមានការចុះបញ្ជីចូលពីប៉ាឡេតនីមួយៗ។ ចំនួនប៉ាឡេតនីមួយៗបង្កើតពីប្រវែងប្លុក / 4។

ការចុះបញ្ជីនីមួយៗមានរាងសាមញ្ញដូចខាងក្រោម;

អំពីពណ៌ក្នុងប៉ាលេត គឺមានតែសេចក្តីថ្លែងបន្ថែមថា សម្រាប់ប៉ាលេតដែលត្រូវបានប្រើសម្រាប់ការបញ្ជូន សេចក្តីឱ្យដឹងដូចខាងក្រោមគឺត្រូវអនុវត្ត:

• ពណ៌ដំបូងគឺត ALWAYS មានភាពថ្លា មិនថាយ៉ាងណាដែលបានកំណត់ក្នុងតម្លៃនោះ។
• ការបញ្ជូលពណ៌ក្នុងប៉ាលេត 1-24 គឺត្រូវបានរាប់ថាជាពណ៌អ្នកលេងក្នុងប៉ាលេត 1-8។
  កន្លែងដែលពណ៌បន្តិចនោះមកពីអ្នកលេង 1 មិនច្បាស់សម្រាប់ខ្ញុំ។
  ខ្ញុំសង្ស័យថាពណ៌ដែលនៅសល់គឺត្រូវបានកំណត់ឱ្យជាពណ៌ត្រឹមត្រូវ

រចនាសម្ព័ន្ធទិន្នន័យនេះនៃឯកសារ PRT បង្ហាញពីរបៀបដែលប៊ីតម៉ាពេលត្រូវបានប្រើសម្រាប់Sprites ត្រូវបានកសាង។ ប៊ីតម៉ានេះគឺជាគ部分មួយ ដែលមានច្រើនត្រូវបានបង្កើតជាការចម្លងមួយនៃឯកសារអានីមេសន៍របស់Sprites ។

ទិន្នន័យរូបភាពជាក់លាក់គឺត្រូវបានលាក់នៅក្នុង op2_art.BMP នៅក្នុងថតហ្គេម។
ហេតុអ្វីបានជាឯកសារប៊ីតម៉ានេះមានក្បាលប៊ីតម៉ា RIFF (ដែលគឺជាការបញ្ជាក់ដែលទាំងមូលមានភាពត្រឹមត្រូវ) គឺមិនច្បាស់។ មានសង្ឃឹមថា Outpost 2 ប្រើ API នៃប្រព័ន្ធដើម្បីបញ្ចូលក្រាហ្វិក ដោយការបង្ហាញក្បាលនេះជាបណ្តោះអាសន្ន ហើយវាក៏ត្រូវបានជំនួសជាលក្ខណៈផ្ទៀងផ្ទាត់ដែលផ្លាស់ប្តូរ។

ទិន្នន័យប៊ីតនៅក្នុងឯកសារ BMP នៅទីតាំង Offset + uint32-Offset, ដែលអាចរកឃើញនៅក្នុងឯកសារ BMP នៅអាស័យដ្ឋាន 0x000A (RIFF-Bitmap-Datenoffset) គឺ អាចរកបាន ហើយវាក៏ត្រូវគ្នានឹងការរៀបចំជួរដេកពីខាងលើខាងឆ្វេងទៅខាងក្រោមផងដែរ។

គ្រាប់ប៊ីតមួយប៊ីត (1bpp) អាចគូរ បានដូចជា ថ្នាក់ទី 0 មានភាពโปร่งពេញ និងថ្នាក់ទី 1 ពីរ៉ែខ្មៅ/ប្រផេះមួយស្រាល ព្រោះគ្រាប់ប៊ីតមូដណែនាំ ត្រូវបានប្រើជាទូទៅសម្រាប់ស្រង៉ៃរថយន្ត និងអគារនៅក្នុងការអានីមេសន៍ ។

ដូច្នេះអ្នកអាចបន្ថែមរូបភាពច្រើនបាន។

ឥឡូវនេះយើងមកដល់ថ្នាក់ខ្ពស់នៃវិន័យក្នុងទ្រង់ទ្រាយទិន្នន័យ Outpost 2៖
ការផ្លាស់ប្តូរ។

listes des animations seront introduites par un en-tête global, qui sert principalement à la vérification des données. Après cela, suivent les définitions concrètes des animations, qui se divisent en 3 niveaux :

1. ការផ្លាស់ប្តូរ
   ការផ្លាស់ប្តូរ គឺជាអង្គភាពកំពូល; វាតំណាងឱ្យការផ្លាស់ប្តូរនៃអង្គភាពមួយ, អគារមួយ ឬ 'ការផ្លាស់ប្តូរ​ជា​ផ្នែក' (ការប៉ះទង្គិចនៃកុមារសារពើភ័ណ្ឌ, អាកាសធាតុ, ការបំផ្ទុះ) នៅក្នុងស្ថានភាពចាប់ផ្ដើមមួយ។
2. រូបភាព
   រូបភាព គឺជារូបភាពមួយក្នុងការផ្លាស់ប្តូរ។ ការផ្លាស់ប្តូរ អាចមានរូបភាពមួយឬច្រើន។
3. រូបភាពឆមាស
   រូបភាពឆមាស គឺជាព័ត៌មានអំពីការដាក់បញ្ចូលថាប៊ីតម៉ាប់ជាក់លាក់មួយត្រូវបានគូសនៅទីតាំងជាក់លាក់នៃរូបភាពមួយក្រោមលក្ខខណ្ឌជាក់លាក់។ រូបភាពមួយអាចមានរូបភាពឆមាសមួយឬច្រើន។

បន្ទាប់មកគឺមានការកំណត់ការផ្លាស់ប្តូរប្រចាំមួយ។

ទិន្នន័យនៃជាតិស្រទាប់ខ្ពស់បំផុត អានីមេישן គឺជាទិន្នន័យគ្រប់គ្រងដែលមានសំខាន់ - Boundingbox បង្ហាញពីសមាសភាពនៃកូអូរដីណាតថ្មីសម្រាប់យានយន្ត/អាគារ នៅពេលដែលវាត្រូវបានជ្រើសរើស ហើយក៏បង្ហាញផងដែរ​ថាតើតំបន់ណាដែលអាចចុចបាន។

Offset កំណត់តំបន់ "ចំណុចសូន្យ"; ចំណុចដែលត្រូវកត់សម្គាល់លើកូអូរដីណាតក្នុងល្បែង ឬដកចេញ។ អ្នកអាចនិយាយថា Offset នៅទីនេះបង្ហាញពីចំណុចដើមនៃកូអូរដីណាត។

Windows ជាមួយនេះគឺដូចជាមួយ Offset ដែលមានតម្លៃ uint(32) ៤ ដែលបានកំណត់ តំបន់ដែលអាចប្រើបានសម្រាប់ Subframes។ ប៊ិចក្រៅ Windows មិនអាចគូរ បានទេ ប្រសិនបើវាត្រូវបានកំណត់សម្រាប់ Bitmap។

នេះអាចឲ្យយើងភ្ជាប់ស៊ុមចេញជា១ៗ និងស៊ុមចេញសរុបសម្រាប់អនុម័តសម្រាប់សកម្មភាពមួយ ដែលបង្ហាញពីសកម្មភាពមួយដែលស្មុគស្មាញ នៅក្នុងសកម្មភាពដែលមានលេខកូដ 500។

ការអានីមេសិន 500 បង្ហាញពីរបៀបដែលយានក្រុង Plymouth ដែលបានបម្រើជាមួយនឹងរ៉ែធម្មតា ត្រូវបានបញ្ចេញ។ វាជាអានីមេសិនមួយក្នុងចំនោមអានីមេសិនតិចតួចដែលប្រើប្រាស់មុខងារ Windowing។

ហើយដូចនេះ អានីមេសិនទាំងមូលអាចត្រូវបានប្រមូលផ្តុំ។
អាសូរ មានបញ្ហាមួយទៀតជាមួយទ្វារលើដែលត្រូវបញ្ចូលកាត់បន្ថយ ពីព្រោះនៅទីនេះ ប៊ីតដែលពាក់ព័ន្ធ មិនត្រូវបានកំណត់ក្នុងព័ត៌មានប្រភេទគ្រាប់រូបភាពទេ។

ទីនេះមានស្រាប់ស្រាប់គ្រាប់រូបភាពដ៏ស្រស់ស្អាតផ្សេងទៀតពីហ្គេម៖

ឥឡូវនេះ យើងកំពុងខ្វះចំពោះឧបករណ៍ប្រើប្រាស់របស់ហ្គេម ដែលមានរូបរាងក្នុងស្តង់ដារដែលមាន ម៉ែតាល់បួស។

ប៉ុន្តែ នៅទីនេះក៏អាចមើលឃើញថា Dynamix មិនត្រូវការបង្កើតការងារថ្មីឡើយ; នៅទីនេះ មិនត្រឹមតែគ្រាន់តែប្រើប្រាស់ API User32 និង GDI32 ដែលផ្តល់ដោយ Windows ទេ - ជាពិសេស ត្រូវបានប្រើប្រាស់ការគ្រប់គ្រងធនធានពី User32 ផងដែរ។

វាត្រូវបានអាចដកស្រង់ឧបករណ៍ទាំងនេះ ដោយឧបករណ៍ដូចជា Angus Johnson ដែលអភិវឌ្ឍន៍ជា Freeware Resource Hacker ឬបើអ្នកមានខ្លាចប្រើប្រាស់ Wine នៅលើ Linux / Mac OS អាចប្រើប្រាស់ wrestool ដែលមាននៅក្នុង icoutils ដើម្បីដកស្រង់ផងដែរ។