Хоть 0,0000000000000001

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

1NzbPAwCzfL3DrPsJBMiQDnvqsGkZ92YD7

Ставим бажный софт, исправляем ошибки и багрепортим.

http://bugs.debian.org/release-critical/debian/all.html

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

Перемещено beastie из development

Книжки, лекции, статьи, личные советы.

Решение:

Завести виртуалки (или железки),
для сборки, написать систему сборки для них,
с предоставлением отчётности.
Писать юнит тесты, или использовать подход TDD.
Тестировать, спотыкаться о грабли, набирать опыта.
Чтить стандарты своего языка, выбирать наиболее полную 
реализацию стандарта.
Разделять платформозависимый код и кроссплатформенный.
При переносе на другие архитектуры, ознакомится с этими архитектурами. 
И да, использовать кроссплатформенные системы сборки, аля СMake.

Купил сегодня пару балончиков для продувки ноута. Сижу,дую во все щели. Хотел было закурить (а сидел в кресле, в закрытом помещении, коморка 3x3 , там всякий хлам хранится.), но прежде невзначай разворачиваю балончик (который на 1 литр) пустой уже и читаю выпучив глаза: Cостав- Пропан,бутан. Курить расхотелось.

Не, а это нормально таким газом заряжать такие шняги?

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

И да, на баллонах никаких предупреждений не было.

Может кто посоветовать рендер (real-time) написаный на Cи, небольшой, на OpenGl 3.3 под lgpl, bsd или mit.

Собственно как? Понимаю можно ручками CSS и прочее, но наверное можно и иначе, к примеру сама документация Doxygen`а выглядит потрясно, может какие профили есть? В доках поиск веду по этому поводу, но что то не найду никак.

Вопрос решен:

Стиль меняется правкой css.

Вертикальное меню добавляется путём:

doxygen -g #генерируем Doxyfile

В Doxyfile выставляем

GENERATE_TREEVIEW    = YES

остальное по вкусу, жизнь прекрасна :)

А ещё лучше взглянуть на оф,доки
file:///usr/share/doc/doxygen/html/index.html
соответственно поставив пакет
(к примеру для debian) doxygen-doc 

Вобщем стукнуло мне в голову следующее.

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

Скажем есть sdl и я решил написать внутренне api для звука и управления окнами в своей программе, я делаю две либы которые предоставляют мне api, но внутри они реализованны на sdl (к примеру можно переписать с allegro, но интерфейс для моей программы останется тем же ) ну так вот каждая из двух либ

по идее должна быть не зависима и вот собственно вопрос. Это нормально что что я каждую буду собирать и линковать динамически с sdl потом прилинковывать ОБЕ к своей программе.

То есть на уровне сырцов меня положено будет расстрелять за то что я буду в каждом lib.c прописывать

#include <stdio.h> #include <stdio.h> #include <SDL/SDL.h>

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

Тем кто в курсе про движок.

С одной стороны MIT, вроде как позиционирую для людей.

С другой стороны LGPL и с закрытым игровым кодом слинковать можно и код открыт останется.

Так что?

Какие подводные камни, куда обратится, нанять юриста или лучше самому?

В C++ так можно, а в C ?

Я никак не могу найти как в стандарте С99 это описано .

Ответ: Нельзя!

Вобщем так кому надо читаем всё по тегу development-game-engine и понимаем про что я говорю, для тех кому лень.......

Думая про то как собственно написать движок не только для себя, а и для теоретической возможности использования другими людьми и целью делать его умеренно простым в использовании всё таки во многих вещах и подходах сомневаюсь.

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

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

Саму сценку по идее можете написать на любом языке, но желательно на си.

Сцена:

У вас есть карта просто комната, у вас есть шарик вы должны катать(или просто передвигать) по комнате шарик в любых направлениях у шарика есть вес его можно подбросить и он упадёт и издаст звук.

Пример от балды не описал работу с мышкой и в условиях ничего не обработал, да там это уже неважно как простой пример сойдёт :

#include "engine.h"

int main()
{
   const int quit=13;
   const int left=1;
   const int roght=2;
   const int boom=3;
   int key=0;

   init_game("game.conf");

   int ball=model_load("ball.obj");
   int room=model_load("room.obj");

   int ball_textur=("ball.tga");
   int room_textur=("room.tga");
   
   int blow=sound_load("blow.ogg");

   impose_textur(ball,ball_textur);
   impose_textur(room,room_textur);
   
   physics_collision(ball,room);
   physics_gravity(room,0);
   physics_gravity(bool,10);

   position(room,0.0,0.0,0.0);
   
   float x_ball=0.0;
   float y_ball=10.0;
   float z_ball=0.0;

   float x_camera=-10.0;
   float y_camera=0.0;
   float z_camera=0.0;

   position(ball,x_ball,y_ball,z_ball);

  int camera=create_camera(x_camera,y_camera,z_camera);

while(key=key_keyboard()!=quit)
{

  if(key==left)
  {
    вертим крутим камеру
    и шарик.

  };
  
  if(key==right)
  {

    вертим крутим камеру
    и шарик 

  };

  if(key==boom)
  {

    
    sound_volume(blow,50);
    sound_play(blow,2);//2 сек.
    
  };


  render();//отрисовываем сцену
};

quit_game(); //выходим из игры

return 0;
};

Ну, а теперь я хотел бы чтобы вы сделали что то подобное, но так как вам хочется как бы вы написали сценку с шариком.

Языков куча, парадигм куча, у каждого языка может быть куча парадигм. Но что предпочитаете вы и в каких комбинациях? Нравятся ли вам хаки или предпочитаете литературный подход. Вобщем почему вы пишете код так как вы его пишете.?

Всё поместить нереально так что сколько влезло с wikiпедии.

Что же продолжу, вчера наткнулся на свою старую доку в которой для себя описывал работу игрового движка который я пытался написать давным, давно(но он канул в лету, мир его праху). Разрабатывая в настоящее время опять движок подумал хоть он и не готов(и будет это ещё не скоро) главное в голове сформирована архитектура на основании которой можно написать вариант использования движка,
для того чтобы стало ясно как с ним работать. И я практически от балды накидал малюсенький шаблон. Она не призвана к тому чтобы объяснить всё. я хочу чтобы вы поняли и рассудили подход к использованию движка, а не конкретный код.

Имена функций и переменных от балды.

Рекомендуется к хоть по беглому взглянуть на это и это.

#include <engine.h>


int map_init()
{
/*
Описание ресурса, движек сам ищет необходимый файл по имени
если путь не указан,так же передаём тип объекта что бы менеджер 
ресурсов знал с чем имеет дело при формировании списка на обработку
конвееру.

*/
int map=load_object("map_street_01",model);                    ///загрузим модель.
int giga_texture=load_object("giga_texture_street_01",texture);///загрузим для неё текстуру.
/*
Физические параметры это тоже объект, это файл
с описанием физических характеристик объекта.
*/
int physix_map=load_object("physix_street_01",physix);         ///загрузим физические параметры.


/*
Виртуальный объект это набор идентификаторов которые передаются 
менеджеру ресурсов по идентификаторам, менеджер ресурсов знает кто чем является 
формирует список и передаёт его конвееру который последовательно прогоняет даные 
по подсистемам и производит все необходимые операции. 
*/
return virtual_object(map,giga_texture,physix_map);///создадим новый объект модель+текстура+физика
};


/*описываем объект*/
int car_init()
{

int car=load_object("car_audi",model);       ///загрузим модель.
int car_texture=("audi_texture_red",texture);///загрузим для неё текстуру.
int physix_car=("audi_physix",physix);       ///загрузим физические параметры.




return virtual_object(car,car_texture,physix_car);///создадим новый объект модель+текстура+физика
};





int main()
{
init_all();                ///лень возиться, инициализируем что есть разом.
base_vfs("/data/data.pak");///указываем  расположение нашей виртуальной фс.
base_dir("/data/conf");    ///указываем  где брать конфиги.
init_config("game.conf");

int map_street_01=map_init_street();///формируем объект карта.
int car_audi_red=car_init();        ///формируем объект бибика.


while(set_key_q!=1)
{

flip_game();///Заводим исполнение конвеера.


/**

GAME CODE

**/

};

quit_all();


return 0;

/**
Список- это последовательность объектов над которыми должны произойти преобразования.

Конвеер это подсистема которая завязывает все остальные подсистемы в цепь обработки.
*/



};

Продолжаем весёлое упарывание технологиями.

Продолжая эту и эту темы.

Более ясно теперь представлена архитектура менеджера ресурсов и
постепенно пилится,поддержка VFS будет реализована посредством
PhysicsFS c которой более менее всё уже ясно, встал вопрос защиты
игровых данных (может и не нужно, скажем что просто я так хочу)

Так вот нужен инструмент для шифрования на лету. Предвидится следующее.

ENGINE ---запрос файла--->PhysicsFS----какая то либа шифрования дешифрования--->файл или образ VFS.

Желательно иметь что то что можно без проблем встроить скажем в PhysicsFS и получим конфетку. Или декодировать данные уже загруженные в память что отожрёт её наверное не хило нуда ладно. truecrypt как пример привёл замечательный зверь, но впихать его куда либо нереально(по моему).

Пинки по ссылкам идеи и здравые советы приветствуются.

Продолжая эту тему.

Для хранения игровых данных и доступа к ним посоветовали в обязательном порядке реализовать работу с VFS и даже посоветовали годную на первый взгляд штуку именуемую PhysicsFS.

На оф. сайте даже ссылки на проекты в которых PhysicsFS используется(но блин там они его по самому минимуму дёргают), более того есть доки оформленные doxygen`ом.

Я один фиг не могу понять каким образом работать с архивами, также не ясно реализована там возможность шифрования данных?

Есть ли люди работавшие с PhysicsFS или видевшие где-то проекты которые его используют для доступа к своим запакованным ресурсам?

Естественно пинки по ссылкам и примеры кода приветствуются.

Голова не варит, поэтому прошу подумать за место моего мозга.

Нужно вот это:

#include <stdio.h>
#include <stdlib.h>

int main()
{

int  num=555;
char str[]="hello";

void * mass[10];

  mass[0]=(int  *)&num;
  mass[1]=(char *)&str;

/**
Всё понятно, дальше отдаём куда хотим определяя тип
*/

//printf("%s\n",(*(char *)mass[1]));//так не работает
  printf("%c\n",(*(char *)mass[1]));//так работает
  printf("%d\n",(*(int  *)mass[0]));

/**
Думаю вопрос понятен.Как отдать строку, а не символ.
*/
 
  return 0;
};

Решение:

printf("%s\n",(char *)mass[1]);

Продолжаю пилить велосипед.

Вообщем так дошло до управления ресурсами выхода два велосипедить или рыться в сторонних движках.

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

При первом варианте думается следующее.

Смотрел как делают велосипедисты на специфичных форумах и абсолютно все сводят к передачи указателя на файл, который и должен использовать пользователь, а работа менеджера сводится к предотвращению дублирования данных и выгрузке не используемых данных.

Может это так принято или удобно разрабам? Обычно делают как передают менеджеру на прямую или косвенно(конфиг например), файл, менеджер регистрирует его выделяет память загружает отдаёт указатель на объект и всё далее сам или по запросу удаляет его и при повторном запросе объекта проверяет есть ли он в индексе своём и если есть снова просто отдаёт указатель на то что уже есть.

Разраб далее работает с указателем как с объектом передавая его туда сюда.

А что если:

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

То есть грузим ---> менеджер регистрирует, грузит, создаёт указатель заносит его в базу генерит идентификатор(просто число int) и отдаёт его разрабу.

Разраб будет иметь просто переменную с идентификатором скажем переменная int monstr. Далее передаёт её скажем рендеру render(monstr,-10,0,0); рендер передаёт значение обратно менеджеру тот ведёт поиск по идентификатору указателя на объект и уже реально передаёт настоящему рендеру косвенно или на прямую производя все необходимые операции.

Вообщем думаю ясно что я хочу нормальный менеджер, но незнаю как его спроектировать, написать то напишу, а вот спроектировать по путному не знаю как.

Жду пинков по ссылкам, примерам, статьям.

Что лучше юзать для автодокументации? doxygen попробовал вроде норм, что ещё есть что стоит попробовать? В лом пробовать всё подряд.

API на языке Си. Те кто работал/работает с игровыми/графическими движками, какое API более удобно было для вас? Что бы вы хотели видеть и иметь? Нужно ли было вам два API низкоуровневое настраивать сам двигатель и высокоуровневое для простой работы с ним.

Чтобы для вас было лучше. К примеру вот так:

/*Initialize systems*/
#define ON       0
#define OFF      1

int init_full    (void);
int init_video   (int on_off);
int init_audio   (int on_off);
int init_keyboard(int on_off);
int init_mouse   (int on_off);
int init_joystick(int on_off);
int init_gebung  (const char input_log_file);

Или вот так:

/*Initialize systems*/

#define ON       0
#define OFF      1

#define FULL     0
#define VIDEO    1
#define AUDIO    2
#define KEYBOARD 3
#define MOUSE    4
#define JOYSTICK 5
#define DEBUNG   6

int init_system(int name_sub_system,int on_off);

То есть иметь функцию с множеством параметров или множество узкоспециализированных функций?

Процедурно ,да, прошу ни слова о плюсах, да я понимаю что от плюсов в этом случае одни плюсы (кому то, но не мне).

Ну и прочие ваши идеи и пожелания.

И снова Debian sid + MATE теперь уже на ноуте. Тема delorean-dark более менее одинаково выглядит как в gtk3 так и в gtk2 приложениях. Иконки снова AwOken. Рамки окон Emerald.

Обоина http://postimage.org/image/fwbwb6tir/e467d217/

Скрин с окнами http://postimage.org/image/pfa75rlix/3f0b2aaa/