{{notification.text}}

MirGames

11.07.11 07:12
0
Глядя на унылый набор вменяемых кроссплатформенных библиотек для C и недоязыка C++, решил таки собрать биндинги ) На данный момент готов почти полный порт заголовочного файла и 4 демки(в svn'е, правда предварительно саму библиотеку надо бы собрать с использованием cdecl и доп. функциями с PChar'ами). В течении дня-двух постараюсь собрать архив с демками для GCC и Visual Studio(правда мороки с установкой всех более-менее распространённых версий...). Для GCC в последствии будет доступен libZenGL.a для статической компиляции на разных платформах включая iOS.
Отредактировано: 11.07.11 23:34
#1
Хранитель Флейма
11.07.11 12:36
0
Andru
Молодца, че. :)
#2
Программир Всия Руси!
11.07.11 17:05
0
Цитата(Andru @ Сегодня, 05:12)
[snapback]108255[/snapback]
Глядя на унылый набор вменяемых кросс-платформенных библиотек для C и недоязыка C++

Это была шутка ведь так же?

Вообще уважающий себя С++ кодер не будет мешать свой софт с богомерзкой Pascal библиотечкой. Ну как бе шутка, но с долей правды.
#3
11.07.11 18:17
0
Цитата(DRON)
Это была шутка ведь так же?

Нет, это было всерьёз(ну почти) :) SDL протух(1.3 всё ещё никак не зарелизится), ClanLib пока не особо кроссплатформенный, cocos2d вроде неплохой представитель(но на десктопе это python), DGLE2 ещё не дорос, PopCap Framework вроде что-то серьёзное, но не внушает, всякое C++ больно уныло и зачастую Win-only или "теоретически кроссплатформенное", либо платное(iTorque 2D там, SIO2) и "покрыто мраком". Количество поделок на коленках - так и вовсе зашкаливает ) И я не один схожего мнения(хотя там причины вроде затерялись где-то). Хочется возразить? Ожидаю список достойных кроссплатформенных 2D движков/библиотек, гуглем пользоваться решительно отказываюсь :) Может for fun поковыряю новые для себя проекты, мнение там изменю... а то пока оно весьма плохое, при таком-то распространении этих ваших С/C++ и количестве "серьёзных деволоперов" 8)

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

Параноики и детвора меня не волнует, больно принципиальные программеры тоже, но против последних ничего против не имею, сам такой )
Отредактировано: 11.07.11 23:35
#4
Хранитель Флейма
11.07.11 19:05
0
Цитата
Вообще уважающий себя С++ кодер не будет мешать свой софт с богомерзкой Pascal библиотечкой.

Ви это так сказали, как будто плюсовики элита какая, б-же ты мой. :lol:
#5
Программир Всия Руси!
11.07.11 21:52
0
Said
Просто я знаю что плюсовики все статически компилируемые языки кроме С++ считают богомерзкими :))

Andru
Ну слушай, бесплатных может в натуре нет, надо поковырять. Из платных дофига хороших. А ваще я поищу... С учетом что на С++ высеров очень много, должно ченить быть же.
#6
11.07.11 22:02
0
Цитата(DRON)
Из платных дофига хороших

Накидой тогда примеров, что ли, один фиг мне надо решать вопрос с лицензией на iOS со статической компиляцией, т.к. не всех LGPL устроит :) Может появится как-нить время чего-то поковырять, над чем работают целые команды.
Отредактировано: 11.07.11 22:02
#7
11.07.11 23:52
0
Собрал архив с 5ю примерами для GCC и Microsoft Visual Studio 2005:
zengl-svn-r1254

внутри 32-битные библиотеки для GNU/Linux и Windows, с поддержкой ogg(посему относительно большой размер).
#8
Dan
The One
12.07.11 02:15
0
Цитата
Вообще уважающий себя С++ кодер не будет мешать свой софт с богомерзкой Pascal библиотечкой. Ну как бе шутка, но с долей правды.

доля правды тут есть, ни Delphi ни FPC не умеют работать ни с SSE ни с другими расширениями процессора. никак абсолютно. поэтому если ты в совей поделке не компенсируешь этот недостаток на ассемблере то C++ программстам в её сторону смотреть и не стоит.
Отредактировано: 12.07.11 02:21
#9
12.07.11 02:28
0
Dan
2D, SSE... по твоему 2D игрушки сейчас упираются в мощности процессора, а не видеокарты? :) 3D я не рассматриваю, т.к. малоинтересная для меня область на данный момент(в плане писать движок/библиотеку и что-либо public в этом направлении, тут уж просто негде найти свою нишу, да и скиллов мне явно не хватит). А в остальном я уже высказался касательно принципов и фобий С/C++ программистов, меня они мало волнуют, вся эта затея с С/C++ не более чем for fun с системщиной :)
Отредактировано: 12.07.11 02:38
#10
Dan
The One
12.07.11 02:44
0
проблемы нехватки оборотов процессороа довольно реальные, особенно для пользователей которые никогда близко не сталкивались с системщиной (они часто берут готовый движок и не думают о том чего может стоить та или иная операция). тот факт что Delphi и FPC сосут у MVS С++ по работе с расширениями процессора ты оспорить не можешь, т.к. это факт. можно лишь компенсировать это ассемблерным кодом. всё что я пытаюсь сказать это то что в шутке упомянутой раньше есть доля праыды и достаточно весомая.
#11
12.07.11 02:59
0
Цитата(Dan)
тот факт что Delphi и FPC сосут у MVS С++ по работе с расширениями процессора ты оспорить не можешь, т.к. это факт

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

Цитата(Dan)
всё что я пытаюсь сказать это то что в шутке упомянутой раньше есть доля праыды и достаточно весомая.

Да я всё понимаю, и реальность той "шутки" далёко не в SSE будет, а в принципиальности программистов :)
Отредактировано: 12.07.11 02:59
#12
Программир Всия Руси!
12.07.11 03:04
0
Dan
То что ты говоришь и есть основа принципов С++ кодера стремящегося к оптимизации.
А вообще известно что в С++ число нубов много меньше чем в Delphi и если уж человек пишет на С++ то он кое-что понимает, как правило.
#13
12.07.11 03:10
0
Цитата
А вообще известно что в С++ число нубов много меньше чем в Delphi и если уж человек пишет на С++ то он кое-что понимает, как правило.

Рыдал, учитывая как исчезающе мало нынче Delphi-кодеров и распространённость C++ ) Да и повидал на своём веку немало "понимающих" С++ деволоперов...
Отредактировано: 12.07.11 03:11
#14
Хранитель Флейма
12.07.11 03:16
0
DRON
Цитата
А вообще известно что в С++ число нубов много меньше чем в Delphi и если уж человек пишет на С++ то он кое-что понимает, как правило.


Бла-бла-бла. Можем продолжит на эту тему в другой ветке, если хочешь, но пока в кратице на правах здоровой дискуссии: уровень профессионала от языка не зависит, количество нубов - понятие относительное, потому что нубы имеют тенденцию становиться матерыми дядьками, либо уходить в другие области в случае затяжных неудач. Плюсовики как правило имеют тенденцию делать простые вещи сложно (ой черт, сейчас я скажу эту набившую оскомину фразу) - а сложные - а сложные им просто сделать не дано. Увы.

З.Ы: Для продолжения обсуждения (если есть желание постоять за свой С++ и немного пофлеймить) предлагаю создать отдельную тему, да и Андру на нас обижаться не будет :)

Andru
Опередил :)
#15
Dan
The One
12.07.11 03:19
0
Andru
скорости относительно геймдева они разные. если ты пишеше тетрис в 2д то тебе абсолютно не нужны никакие оптимизации, блни нужно быть гением чтобы написать тормозящий тетрис. а вот тесли ты пишешь акшион рпг с видом от фпс то тут очень сильные наклады случаются, очень часто эти наклады приходится скидывать на дополнительные ядра процессора, но если такой возможности нет то приходится оттачивать свой код до самых нужностей, а паскальные компиляторы этого просто не умеют. блин FPU код паскальных компиляторов отстаёт от ява скрипта по производительности, что тут ещё можно сказать?!
Отредактировано: 12.07.11 03:21
#16
12.07.11 03:29
0
Цитата
блин FPU код паскальных компиляторов отстаёт от ява скрипта по производительности, что тут ещё можно сказать?!

Тоже читал эту статейку? Надо бы на днях сесть поковырять это с FreePascal'ем, ради интереса, а то я как-то пропустил всю эту феерию по причине занятости )
#17
Dan
The One
12.07.11 03:58
0
я уже ковырял, сначала сам не поверил, как так интерпритируемый скриптовой язык быстрее чем компилируемый. переписал код на делфи и фри паскале, но сцука пацан правду говорит... паскаль сосёт. потом начал смотреть на асемблерный код который делфи генерирует, там всё на старомодном fld, fstp и т.д.
Отредактировано: 12.07.11 04:00
#18
12.07.11 13:52
0
С++ говно
что уж тут )

Andru
хочу посоветовать не использовать либы, а всего один *.h
есть подход с динамической инициализацией
я реализовал автоматическую )

но в твоём случае наверно нужен будет какой-то кодогенератор )

http://zalil.ru/31410398
Отредактировано: 12.07.11 14:00
#19
12.07.11 15:14
0
Цитата(Devil)
хочу посоветовать не использовать либы, а всего один *.h
есть подход с динамической инициализацией

Эммм, ты архив то смотрел? Там всё динамически :) Стат. либы нужны только в случаи если не охота таскать с собой so/dll/dylib, или нет возможности это сделать(iOS).

И да, твой способ весьма жирный, т.к. объявляешь тип функции, а потом указатели с этими типами которым будут присваивается адреса через GetProcAddress. Что бы обойти проблемы преобразования типов сварганил такое:
Код

  #if ( defined __MINGW32__ || defined __MINGW64__ )
    #define zglGetAddress( a, b, c ) a = (__typeof__(a))GetProcAddress( b, c )
  #else
    #define zglGetAddress( a, b, c ) *(void**)&a = (void*)GetProcAddress( b, c )
  #endif

юзается так:
Код

zglGetAddress( zgl_Init, zglLib, "zgl_Init" );

где zgl_Init указатель на функцию, куда будет присвоен адрес, zglLib - загруженная библиотека, ну и название.
#20
12.07.11 16:02
0
Andru
крутебл
#{{post.Index}}
{{post.Author.Login}}
{{post.CreatedDate | date:'dd.MM.yy HH:mm'}}
{{post.VotesRating}}
Отредактировано: {{post.UpdatedDate | date:'dd.MM.yy HH:mm'}}