SGDK

[ALKO]

Застопорился на освоении вывода спрайта.

Текст и тайлы вывести могу. А спрайт - ни в какую.
Точнее экземпл с вики работает. А моё - не пашет. (компилит без ошибок)

Вот мой исходник.

#include <genesis.h>


struct genresTiles
{
		u16 *pal; 		//pointer to pal data
		u32 *tiles;		//pointer to tiles data
		u16 width;		//width in tiles
		u16 height;		//height in tiles
		u16 compressedSize; //0 in this demo, more coming soon
};
extern struct genresTiles title;

struct genresSprites
{
		u16 *pal; 		//pointer to pal data
		u32 **sprites;		//pointer to sprites data
		u16 count;		//nb sprites
		u16 width;		//width of each sprite in pixels
		u16 height;		//height of each sprite in pixels
		u16 size; 		//since we use width/height in pixel, useful info on sprite size
						//TODO : size is not SGDK compliant, you need to use size>>8
						//		will be fixed in coming release
};
extern struct genresSprites bat1;


#define TILE1	1

int main( )
{
SpriteDef mySprite;
	
	u8 frame = 0;

	VDP_setPalette(PAL1, title.pal);

	// load tiles in VRAM
	//  arg0 = tiles data
	//  arg1 = index for first destination tile
	//  arg2 = number of tiles to load
	//  arg3 = use DMA (1) or not (0)
	VDP_loadTileData(title.tiles, TILE1, title.width*title.height, 0);
	
//	VDP_fillTileMapRectInc(BPLAN, TILE_ATTR_FULL(PAL1, 0, 0, 0, TILE1), 0, 0, title.width, title.height);
	
	VDP_resetSprites();
	VDP_setSprite(0, 0, 0, bat1.size>>8, TILE_ATTR_FULL(PAL1,1,0,0,TILE1), 1 /* 0 */);

        
        // define the sprite (using a _spritedef to easily make Sonic move later)
   // define the sprite (using a _spritedef to easily make Sonic move later)
        mySprite.posx = 40;
        mySprite.posy = 40;
        mySprite.size = bat1.size>>8;
        mySprite.tile_attr = TILE_ATTR_FULL(PAL1,1,0,0,1);
        mySprite.link  = 0;
        VDP_setSpriteP(0, &mySprite);

	
	
	while(1)
	{
	       VDP_setSpriteP(0, &mySprite);
	  VDP_updateSprites();
	VDP_waitVSync();
	}
	return 0;
}

Содержимое файла, задающего ресурсы.

BITMAP title "data/title.bmp" 0
SPRITE bat1 "data/bat.bmp"  56 16 0

Обе битмапы 4-ёх битные.
title.bmp выводит без проблем.
bat.bmp - не отображает.

А вот исходник с вики по SGDK

http://sgdk.googlecode.com/svn/wiki/...itesGenRes.zip

[Advertiser]

[ALKO]

Интересно было бы реализовать на сеге трёхмерный низко-полигональный мир.
Знаю, есть на форуме спецы по векторному 3д графону. Интересны алгоритмы рисования трёхмерной геометрии по точкам, с учётом оптимизации по тригонометрии и разного рода арифметическим операциями (например замена умножения\деления на регистровые сдвиги, сложение на логические операнды).

В этой СДК есть возможность рисования как отдельных точек (типа спектрумовского POINT X,Y ), так и готовая ф-ция рисования и заливки определённым цветом полигона. (идущий в комплекте с СДК пример, где вращается кубик с плоскостным тонированием, шикарен, но в исходнике сложновато разобраться. Хотя если его кто-нибудь бы подробно разжевал, то можно было бы взять за основу).

[Бука]

было бы реализовать на сеге трёхмерный низко-полигональный мир.

Для Сеги были неплохие авиасимы с честными 3д-полигонами (заливка цветом).

Недавно сваяли Вольфенштейн 3Д.

[ALKO]

Для Сеги были неплохие авиасимы с честными 3д-полигонами (заливка цветом).

Знаю. Игор с полигональной 3д графикой на сеге можно по пальцам пересчитать. Есть конечно убер-тормозные (steel taloon, mig-29). Но некоторые из них вполне шустрые по производительности, типа движка Kawasaki, в котором даже есть вращение спрайтов и слоя, что тоже довольно ресурсоёмко (вот только в Kawasaki нет учёта перспективы по оси Y, но её нет и в первом думе, и дюке нюкеме и множестве гоночек на ДОС).

Недавно сваяли Вольфенштейн 3Д.

Там не полигональный графон. Да и по принципу построения картинки сложно назвать это 3д-графикой.

- - - Добавлено - - -

с честными 3д-полигонами (заливка цветом).

Вращающийся кубик из примера СДК дежится стабильно на 20-ти FPS как при режиме wireframe,так и при режиме плоскостного тонирования и максимальном приближении камеры.
То есть тут сказывается в основном не заливка полигонов, а обновление координат вертексов в пространстве.

Вот при текстурировании - да, массив пикселей на экране даёт о себе знать.

Скрытый текст

[свернуть]

[Бука]

Есть конечно убер-тормозные

Когда-то у меня был карик Ф-15, много летал. Тормозов особых не было.

Вот при текстурировании - да

Да уж, Генесис ни разу не 3дэ консоль... Под спрайты заточена, как почитал про управление её ВДП удивился что вообще хоть какие-то 3д игры были.

[ALKO]

как почитал про управление её ВДП удивился что вообще хоть какие-то 3д игры были.

Ну а чё, на спектруме куда геморнее выводить пиксели, да ещё и буфер кадра нужен. На сеге же буфер кадра - оператива VDP. Пусть и разбитая по тайлам, но не такая мозговыносная адресация, как на спектруме, однако при всём при этом на спектруме чуточку больше полигональных игор, вроде.

[Бука]

На сеге же буфер кадра - оператива VDP.

Так емнип в неё же проц напрямую писать не может, только командовать ВДП?

[ALKO]

Ещё вопрос по игровой логике. При программировании такой чахленькой ЭВМ нужно учитывать каждый такт.

Адекватно ли делать таким образом ? :
bool init_level_flag;
bool init_effects_flag;
bool game_over_flag;
bool effect_flag;

main()
{
...
while(TRUE)
{
if(init_effects_flag)initEffect();
if(effect_flag==TRUE)effect();
if(init_level_flag==FALSE)initLevel();
if(game_over_flag==FALSE)updateGame();
else zastavka();
...
}
}

Короче, если в главном цикле таким образом накопится куча if'ов, это не нормально же, так ведь? Как оптимальнее делать ?

- - - Добавлено - - -

Так емнип в неё же проц напрямую писать не может, только командовать ВДП?

Кажись, да.
Получается, что сперва надо рисовать в системное ОЗУ, и лишь оттуда уже перегонять в VDP...

- - - Добавлено - - -

для удобства я выношу проверки флага в каждую отдельную функцию, а в главном цикле поочерёдно вызываю все функции, и внутри функции проверка, если функция неактивна, то она скипается.
Но так или иначе, проверки вхолостую происходят. Не чересчур ли это *****кодерство ?

- - - Добавлено - - -

Сатанизьм.


- - - Добавлено - - -

Сперва думал о процедурном отзеркаливании фона (зеркалка на сеге работает только по тайлам 8*8, а не по целому фону, в связи с чем надобно весь массив тайлов в обратном порядке выстраивать).

Но как я понял, компилятор ресурсов сам определяет симметрию картинки, и компрессирует в нужном направлении.
http://gendev.spritesmind.net/forum/...hp?f=19&t=2144

[ALKO]

Когда-то у меня был карик Ф-15, много летал. Тормозов особых не было.

Погонял малость, тормоза приличные. Особенно с видом chase view. Даже тормознее чем MIG-29. Где-то на уровне 3д-гольфов (серии PGA Tour Golf).
Причём сказывается в основном не количество полигонов, а закраска полигонов. Если даже будет один сплошной полигон террейна, то лагать будет прямо пропорционально количеству заливки.

F-117 Night Storm немножко быстрее рендерится. Там, пожалуй, самый шустрый движок среди всех 3д-полигональных сеговских авиа-симов.

А вообще, Gasega (автор вульфовского порта) начинал как-то лепить стар-фокс. Вот только давно обновлений не было. Забил, видать (активнее работает над MODE7).

Скрытый текст

[свернуть]

Сам движок ближе к Kawasaki (и F-1). Тоже есть наклоны бэкграунда, тоже нет перспективы по оси Y.
Только есть ещё динамический меш, тонирование в глубину и даже текстурирование (на видео нет, но в одной из демок можно увидеть. Но то текстурирование не труЪ. Просто морфящаяся картинка, как стены в Zero Tolerance или Blood Shot'e).

- - - Добавлено - - -

А вот во времена нинтендовского старфокса сеговские разрабы тоже хотели замахнуться на подобное.
Но игру так и не релизнули.

Скрытый текст

[свернуть]

[HardWareMan]

Ты не поверишь, на что замахивались именитые демомейкеры в 90х...