ASTEROIDS на УКНЦ

[S_V_B]

зачем тебе динамическая память?
у тебя есть максимальное количество обьектов, их и обрабатывай.

Если отбросить выделение памяти то так и будет. Только есть одно НО - максимальное кол-во это количество одновременно выводимых на экран, но количество объектов непостоянно и мы их добавляем и убираем непоследовательно, соответственно нужно отслеживать занятые и освободившиеся участки памяти. Вот я и думаю как лучше сделать - отдельным массивом или в каждом элементе сделать признак занятости. Или еще как.

[S_V_B]

Тут дело даже не в том "почему и как", а в том как это сделать быстро и красиво.. без лишних "движняков"

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

Да и объектов будет чуть больше но не суть.. (например мы разбили большой астероид, а из него получилось два маленьких.. с вектором +-45)..

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

ТО что например было в LM(LastMission) .. я заранее знал, что в комнате будет восемь врагов.. и при их уничтожении .. их становится только меньше..т.е. ты их не отображаешь..
Как вариант - партиклсистемс.. ну например мы захотим хвост за кораблем сделать..

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

P.S.
Последние десять лет я занимаюсь сиквелом, от которого меня тошнит
Не имея опыта разработки игрушек на асме тем более PDP-11 я надеюсь найти понимание от ГУРУ. (и надеюсь, что мои "мысли в слух".. помогут такому же.. страждущему).
Может я не умею искать в ГУГЛЕ но я не нашел ничего мало-мальски интересного.
По сему считаю ВАЖНЫМ то, что пытаюсь сделать (с вероятностью 10% кто-то тоже ищет эту информацию ).

[TheGWBV]

Может быть так...
Пока объект состоит из одного элемента, то его ID описывается в 16-ти битном слове: b11111111'00000000, где 00000000 - байт описывающий количество частей, на которые разделился объект после столкновения с другим.
Тогда остаётся только определиться с макс. Количеством осколков объекта, продумать таблицу свойств объекта и его осколков, которая будет храниться в ОЗУ, пока объект отображается на экране, но может быть выгружена, или удалена, для освобождения памяти под другие объекты, когда объект уже не нужен, или вскоре не понадобиться для отображения на экране.

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

Таким образом, у каждого осколка уже заранее определён свой ID...

Старший байт - это основной ID, в котором можно шифровать по маске и тип объекта, и его номер.
Ну, и основному ID можно выделить 12 старших бит, а осколкам - 4 бита, в ID

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

Прочитав ID как слово, сразу становится известно о типе объекта, есть ли у него осколки (или спутники), и как глубоко шерстить таблицу осколков, исходя из их количества...

[S_V_B]

Тогда остаётся только определиться с макс. Количеством осколков объекта, продумать таблицу свойств объекта и его осколков, которая будет храниться в ОЗУ, пока объект отображается на экране, но может быть выгружена, или удалена, для освобождения памяти под другие объекты, когда объект уже не нужен, или вскоре не понадобиться для отображения на экране.

Чет.. ты замутила.. .... основной принцип программирования - "делай это проще".. тут нам уже пентиум нужен
Согласен, для осколков выделим отдельный кусок памяти.. партиклы будут закользованы отдельно - объекты отдельно. "мухи и котлеты"

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

для осколков

Не путать с объектом -астероид.
Партиклы- частицы, для красоты.

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

Но если ты подстрелил большой астероид - получишь два маленьких (объекта).

[jerri]

Если отбросить выделение памяти то так и будет. Только есть одно НО - максимальное кол-во это количество одновременно выводимых на экран, но количество объектов непостоянно и мы их добавляем и убираем непоследовательно, соответственно нужно отслеживать занятые и освободившиеся участки памяти. Вот я и думаю как лучше сделать - отдельным массивом или в каждом элементе сделать признак занятости. Или еще как.

А зачем у тебя разная размерность описателей для обьектов?
это же непрактично

[TheGWBV]

Чет.. ты замутила.. .... основной принцип программирования - "делай это проще".. тут нам уже пентиум нужен
Согласен, для осколков выделим отдельный кусок памяти.. партиклы будут закользованы отдельно - объекты отдельно. "мухи и котлеты"

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


Не путать с объектом -астероид.
Партиклы- частицы, для красоты.

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

Но если ты подстрелил большой астероид - получишь два маленьких (объекта).

Если подстрелил астероид, то он исчезает, т.к. количество осколков не равно 1, и не равно 0, но равно 2 Но появляются осколки - 2 шт.
Если бы кол-во осколков стало 1, то появился бы, например, астероид с трещиной (который при следующем попадании в него непременно расколется)...
Чтобы шерстить таблицу не надо Пентиума, нужно её тщательно продумать, с учётом возможности использовать модифицирующийся код и косвенно - индексную адресацию, например.

[Advertiser]

[S_V_B]

А зачем у тебя разная размерность описателей для обьектов?
это же непрактично

Не совсем так.

Или лучше разбить на участки по объекту максимального размера?

Но не стоит сюда впихивать партиклы - они гораздо проще.

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

Тогда остаётся только определиться с макс. Количеством осколков объекта, продумать таблицу свойств объекта

Я думаю, что проще большой астероид (как в оригинале) разделять на два +-45 по ходу движения с масштабом в два раза меньше. И это будет просто два новых объекта которые при попадании будут просто уничтожаться. В любом случае для этих дел памяти должно хватить и нужно делать все максимально линейно и быстро.

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

А на чсчет партиклов, это если останется запас по быстродействию, для антуража

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

Лет двадцать назад увлекался OpenGL, были вещи которые реально мотивировали Например как шикарно смотрелся дым от паровоза в игре Comandos, сразу решено было повторить
Уже не помню как называются полигоны всегда повернутые к зрителю.. билборды вроде.. было здорово, но это не про УКНЦ

[nzeemin]

Я думаю, что проще большой астероид (как в оригинале) разделять на два +-45 по ходу движения с масштабом в два раза меньше. И это будет просто два новых объекта которые при попадании будут просто уничтожаться. В любом случае для этих дел памяти должно хватить и нужно делать все максимально линейно и быстро.

Наконец-то разумные мысли.
Вообще на каждый объект должно быть достаточно:
- тип - один байт - определяет размер + ориентацию, либо ориентация отдельным байтом
- координаты X и Y - два слова
- скорости по X и Y - два слова
Итого - 5 слов, 10 байт.

Сейчас самое важное - сделать тест производительности, определить сколько и каких объектов УКНЦ потянет без задержек - от этого уже всё остальное зависит.

[S_V_B]

Сейчас самое важное - сделать тест производительности, определить сколько и каких объектов УКНЦ потянет без задержек - от этого уже всё остальное зависит.

По отдельности все процедуры уже готовы, осталось все в кучу собрать, надеюсь на выходных дадут мне этим заняться

[BlaireCas]

Исходники KRAKOUT-a (сорри не выложил раньше).
Там есть процедурки для музыки в периферийном процессоре. Насколько помню это была некая жуть с портами Типа tst @#177714 по нескольку раз делать (одного нехватало). Спасибо тут люди помогли.
Музыкальные вещи в KRKPPU.MAC
Для полноценного компиляния будет нужен php и rt11.exe (не включаю их). Ну и вообще там crazy code в куче мест Но вдруг кому надо будет мол как работать с переферийным процессором и музыкой/звуками встроенной пищалки.
krk_src.zip

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

Кстати на УКНЦ я бы не про астероиды, а про River Raid подумал бы. Времени нет помучаться, а так с УКНЦшным скроллом через таблицу строк экрана - самое оно бы было. Но если астероиды получатся - то тоже очень неплохо будет.