- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
void load_functions(void** functions[], const char* names[], ushort count)
{
for(ushort i=0; i<count; i++)
*functions[i]=wglGetProcAddress(names[i]);
}
...
void* const glslFunctions[]={&glCreateShader, &glShaderSource, &glCompileShader,
&glGetShaderiv, &glGetShaderInfoLog, &glDeleteShader,
&glCreateProgram, &glAttachShader, &glLinkProgram, &glGetProgramiv,
&glGetProgramInfoLog, &glUseProgram, &glDeleteProgram,
&glGetUniformLocation, &glGetActiveUniform, &glBindAttribLocation,
&glGenProgramPipelines, &glBindProgramPipeline, &glDeleteProgramPipelines, &glUseProgramStages,
&glProgramParameteri, &glGetProgramPipelineiv, &glValidateProgramPipeline, &glGetProgramPipelineInfoLog,
&glProgramUniform1i, &glProgramUniform2iv, &glProgramUniform3iv, &glProgramUniform4iv,
&glProgramUniform1ui, &glProgramUniform2uiv, &glProgramUniform3uiv, &glProgramUniform4uiv,
&glProgramUniform1f, &glProgramUniform2fv, &glProgramUniform3fv, &glProgramUniform4fv,
&glProgramUniform1d, &glProgramUniform2dv, &glProgramUniform3dv, &glProgramUniform4dv,
&glProgramUniformMatrix2fv, &glProgramUniformMatrix3fv, &glProgramUniformMatrix4fv,
&glProgramUniformMatrix2x3fv, &glProgramUniformMatrix2x4fv,
&glProgramUniformMatrix3x2fv, &glProgramUniformMatrix3x4fv,
&glProgramUniformMatrix4x2fv, &glProgramUniformMatrix4x3fv,
&glProgramUniformMatrix2dv, &glProgramUniformMatrix3dv, &glProgramUniformMatrix4dv,
&glProgramUniformMatrix2x3dv, &glProgramUniformMatrix2x4dv,
&glProgramUniformMatrix3x2dv, &glProgramUniformMatrix3x4dv,
&glProgramUniformMatrix4x2dv, &glProgramUniformMatrix4x3dv};
const char* glslFuncNames[sizeof(glslFunctions)/sizeof(glslFunctions[0])]=
{"glCreateShader", "glShaderSource", "glCompileShader",
"glGetShaderiv", "glGetShaderInfoLog", "glDeleteShader",
"glCreateProgram", "glAttachShader", "glLinkProgram", "glGetProgramiv",
"glGetProgramInfoLog", "glUseProgram", "glDeleteProgram",
"glGetUniformLocation", "glGetActiveUniform", "glBindAttribLocation",
"glGenProgramPipelines", "glBindProgramPipeline", "glDeleteProgramPipelines", "glUseProgramStages",
"glProgramParameteri", "glGetProgramPipelineiv", "glValidateProgramPipeline", "glGetProgramPipelineInfoLog",
"glProgramUniform1i", "glProgramUniform2iv", "glProgramUniform3iv", "glProgramUniform4iv",
"glProgramUniform1ui", "glProgramUniform2uiv", "glProgramUniform3uiv", "glProgramUniform4uiv",
"glProgramUniform1f", "glProgramUniform2fv", "glProgramUniform3fv", "glProgramUniform4fv",
"glProgramUniform1d", "glProgramUniform2dv", "glProgramUniform3dv", "glProgramUniform4dv",
"glProgramUniformMatrix2fv", "glProgramUniformMatrix3fv", "glProgramUniformMatrix4fv",
"glProgramUniformMatrix2x3fv", "glProgramUniformMatrix2x4fv",
"glProgramUniformMatrix3x2fv", "glProgramUniformMatrix3x4fv",
"glProgramUniformMatrix4x2fv", "glProgramUniformMatrix4x3fv",
"glProgramUniformMatrix2dv", "glProgramUniformMatrix3dv", "glProgramUniformMatrix4dv",
"glProgramUniformMatrix2x3dv", "glProgramUniformMatrix2x4dv",
"glProgramUniformMatrix3x2dv", "glProgramUniformMatrix3x4dv",
"glProgramUniformMatrix4x2dv", "glProgramUniformMatrix4x3dv"};
load_functions((void***)glslFunctions, glslFuncNames, sizeof(glslFunctions)/sizeof(glslFunctions[0]));
...
gammaker 28.07.2012 16:35 # 0
sayidandrtfm 28.07.2012 17:11 # 0
> load_functions (...,sizeof(...));
?
P.S. Смотри, он будет рисовать картину...уже расширил ОпэнЖоЭль.
bormand 28.07.2012 17:15 # +1
gammaker 28.07.2012 17:29 # 0
bormand 28.07.2012 17:35 # +4
2) Это не даст никакой экономии памяти.
3) Может не хватить диапазона (в данном конкретном случае хватит, я согласен).
Поэтому short'ы вне массивов и структур не имеют особого смысла...
gammaker 28.07.2012 17:47 # 0
А я думал, что одинаково. 16-битные регистры же есть: ax, bx, cx, dx. Почему же они медленнее? А что насчёт 64-разрядных процессоров? Сейчас же уже все процессоры 64-разрядные, но многие программы 32-битные. 32-битные операции тоже медленные?
guest 28.07.2012 17:49 # +3
gammaker 28.07.2012 17:54 # 0
bormand 28.07.2012 18:01 # +1
guest 28.07.2012 19:56 # +3
bormand 28.07.2012 17:57 # +4
Во вторых 16битные mov и ему подобные вносят ненужную зависимость от старого содержимого старших бит, что мешает процу распараллеливать операции.
Ну а вообще да, в основном будут с такой же скоростью работать. Вот только быстрее чем 32хбитные - никак.
TarasB 28.07.2012 18:25 # +2
> void load_functions(void** functions[], const char* names[], ushort count)
Ну неужели двойная звёздочка, да ещё и с [] (хорошо хоть что не тройная) не смущает автора? Или он привычен? Я вот секунд 15 вдуплял, что там на что там на что там на что там указывает.
gammaker 28.07.2012 18:37 # 0
Ну я конечно хотел как-нибудь её убрать, но не придумал как. У меня такая функция единственная во всём движке. Но вроде всё понятно: массив указателей на указатели на функции.
>Я вот секунд 15 вдуплял, что там на что там на что там на что там указывает.
Вот и отлично. Чтобы понять мой механизм загрузки расширений нужно всего лишь каких-то 15 секунд.
HaskellGovno 28.07.2012 18:41 # 0
gammaker 28.07.2012 18:46 # 0
TarasB 28.07.2012 22:41 # +4
HaskellGovno 29.07.2012 07:40 # +2
bormand 29.07.2012 08:04 # +4
TarasB 29.07.2012 13:14 # +2
HaskellGovno 29.07.2012 13:16 # 0
TarasB 29.07.2012 22:36 # +1
HaskellGovno 29.07.2012 22:42 # −1
Посмотри на код ниже. Он успешно передаёт размер контейнера сам и не требует передавать его отдельно.
TarasB 29.07.2012 22:58 # +1
HaskellGovno 29.07.2012 23:10 # +3
gammaker 30.07.2012 13:45 # −5
zim 30.07.2012 15:06 # +1
HaskellGovno 30.07.2012 15:34 # +1
HaskellGovno 29.07.2012 14:03 # 0
HaskellGovno 29.07.2012 22:44 # 0
fixed
HaskellGovno 29.07.2012 14:05 # 0
Получилось бы более обобщённо. А Ада так может?
HaskellGovno 29.07.2012 14:08 # 0
template<template<class > class Container>
void load_functions(const Container<FunctionInfo> &functions)
HaskellGovno 29.07.2012 22:20 # 0
Это совершенно не будет работать.
Для тогоже std::vector придется написать
А для std::set:
Для какого-то своего контейнера с каким то другим числом параметров. А потом стандарт поменяют и старый код перестанет компилироваться. Бесполезно всё это... Убогие кресты не могут в обобщенное программирование.
HaskellGovno 29.07.2012 22:23 # 0
defecate-plusplus 29.07.2012 22:32 # 0
template <template ...> нужен только тогда, когда код внутри шаблона собирается инстанциировать шаблонный класс несколько раз и по-разному
если ожидать Container<FunctionInfo> (т.е. тебе нужна только 1 версия), то и ожидай уже полностью инстанциированный тип:
HaskellGovno 29.07.2012 22:40 # 0
Опасно это. По тихому преобразоваться тип может. Например, foo - указатель, а Container - контейнер boolов. К тому же некоторые питушки иногда создают свои операторы приведения типов. Вообщем не вариант с точки зрения обобщения. Нужна надежная проверка типа в месте использования функции.
Да и вообще показывать на ошибку вызова функции не в месте вызова функции, а в глубине библиотеки после цепочки вызова шаблонных функций - моветон.
defecate-plusplus 29.07.2012 22:46 # 0
ну а про ошибку в месте вызова функции - притянуто за уши
писать template <template ...> ради кода выше - говнокод, как раз именно потому, что лишняя работа, которая серьезно сужает применимость
TarasB 29.07.2012 22:35 # 0
HaskellGovno 29.07.2012 22:41 # 0
____________________
Отредактировал пост:
ЗЫ: А вы про Аду... Ок
TarasB 29.07.2012 22:59 # 0
defecate-plusplus 29.07.2012 22:59 # 0
тут написано, что генерик использует параметр P1 как другой генерик с известным уже именем Q, и задает ему либо все параметры, либо использует все по умолчанию
т.е. это примерно как использовать std::vector<mytype, std::allocator<mytype> >, а не Container<mytype>
вот такой код на Аде можно написать?
HaskellGovno 30.07.2012 09:45 # 0
Тарас молчит, а значит его тоже гложут сомнения.
TarasB 30.07.2012 09:52 # 0
я эту фичу не пользовал, что умеют пакеты в параметрах шаблона - не знаю.
Если что, можно тупо так:
dosmth<std::vector<int>, std::vector<double>>();
defecate-plusplus 30.07.2012 10:46 # 0
хотя бы в вот такой паттерн ада может?
(это один из обходов ситуации с template <template ...>)
http://ideone.com/Pxlpt
HaskellGovno 30.07.2012 12:53 # 0
>St3setIiSt4lessIiESaIiEE
can not into деманглинг, братюнь?
defecate-plusplus 30.07.2012 13:27 # 0
в студии тот же код выводит сразу нормально
интернет подсказывает, что в гцц есть abi::__cxa_demangle - лишние телодвижения
HaskellGovno 30.07.2012 13:38 # 0
Именно.
HaskellGovno 30.07.2012 12:57 # 0
defecate-plusplus 30.07.2012 13:28 # +2
в студии, где инстанциирование шаблона не 2х этапное, как требует стандарт, как раз template внутри можно не писать
HaskellGovno 29.07.2012 08:24 # −1
bormand 28.07.2012 17:03 # +2
gammaker 28.07.2012 17:15 # 0
gammaker 28.07.2012 18:30 # 0
И ещё я вспомнил, почему я решил сам загружать расширения: я пытаюсь загружать сначала функционал ядра, но если он не поддерживается, то загружаю аналогичное расширение на место тех же функций для совместимости. А в библиотеках типа glew они загружаются отдельно.
HaskellGovno 28.07.2012 17:05 # 0
gammaker 28.07.2012 17:34 # 0
Да и просто так, выложил, потому что нигде подобного не видел. Везде загружают функции по одной с кастами.
bormand 28.07.2012 17:41 # +5
gammaker 28.07.2012 17:50 # +4
HaskellGovno 28.07.2012 17:52 # 0
bormand 28.07.2012 18:03 # +1
HaskellGovno 28.07.2012 18:02 # 0
bormand 28.07.2012 18:17 # +1
чтобы она в конструкторе сама дергала wglGetProcAddress() (если, конечно, его можно вызывать до вызова main())
FIX: макрос вместо функции, т.к. надо имя функции передавать в wglGetProcAddress.
HaskellGovno 28.07.2012 18:24 # 0
А пример можете?
bormand 28.07.2012 18:47 # 0
WARNING. Я не помню, можно ли вызывать wglGetProcAddress до main(), и какие инициализации надо провести перед его вызовом. Поэтому этот код лучше не юзать в продакшене.
P.S. Зато тут не нужны кодогенераторы, функция описывается 1 раз в одной точке...
gammaker 28.07.2012 18:53 # 0
Нельзя. Тем более, что ещё нужно сначала инициализировать контекст OpenGL. Без него будет всегда возвращаться нулевой указатель.
bormand 28.07.2012 19:16 # 0
Вот такой вот говнокодик, поддерживающий отложенную загрузку. Вам скорее всего не подойдет из-за буста и требуемых особенностей загрузки... Но пусть лежит тут как proof-of-concept ;)
P.S. Торопился, поэтому смотрится как говно.
bormand 28.07.2012 19:23 # 0
Эх, ладно, ни к чему все это...
guest 28.07.2012 22:57 # 0
Лол. std::function давно уже в стандарте. Его и используй.
bormand 29.07.2012 06:15 # 0
HaskellGovno 29.07.2012 07:42 # −1
gammaker 29.07.2012 10:56 # 0
HaskellGovno 29.07.2012 13:10 # 0
gammaker 29.07.2012 15:24 # +1
HaskellGovno 29.07.2012 22:28 # +1
А как вы обходитесь без лямбд с замыканиями, без каррирования и объектов первого класса? Это же так способствует надежности, декларативности и обобщенности.
gammaker 30.07.2012 13:53 # 0
Так что я выкладываю свои последние говнокоды в разделе C++...
HaskellGovno 30.07.2012 14:58 # 0
Для Higher Order Functions это нужно.
guest 28.07.2012 22:56 # −2
bormand 29.07.2012 05:47 # 0
Помешать отсутствие виртуального деструктора может разве что так: кастануть объект в boost::function<T*>*, а потом сделать ему delete, но зачем...
bormand 29.07.2012 05:56 # 0
USB 28.07.2012 23:06 # 0
Для этого можно написать обертку над wglGetProcAddress, которая будет инициализировать GL при первом вызове, если она ещё не инициализирована.
sayidandrtfm 28.07.2012 18:11 # +2
Внешний скрипт коллектор-кодогенератор перед компиляцией?
bormand 28.07.2012 18:12 # +1
Там почти весь исходник сгенерен из спецификаций расширений OpenGL.
sayidandrtfm 28.07.2012 18:13 # 0
Интересен уже общий случай с подобной инициализацией.
HaskellGovno 28.07.2012 18:38 # 0
Пых или питон же
gammaker 28.07.2012 18:42 # 0
#define glGenerateTextureMipmapEXT GLEW_GET_FUN(__glewGenerateTextureMipmap EXT)
Я не понимаю, зачем это сделали? Для ленивой инициализации что ли? А IDE даже подсказок не отображает.
gammaker 28.07.2012 19:07 # 0
Try 28.07.2012 22:40 # 0
А так сойдет?
gammaker 29.07.2012 10:59 # 0
Try 30.07.2012 19:55 # 0
Но, как говориться: хозяин - барин.
gammaker 31.07.2012 12:39 # 0
HaskellGovno 31.07.2012 12:43 # +1
gammaker 31.07.2012 12:54 # −2
guest 31.07.2012 15:54 # +4
> C# будет импортировать эти функции.
И ты, после упоминания C#, пытаешься упоминать, что заботишься о размере файлов?
3.14159265 31.07.2012 16:34 # +1
Пхпешник и экономия на спичках
absolut 31.07.2012 16:40 # 0
про зажигалку?
gammaker 31.07.2012 16:56 # −1
bormand 31.07.2012 17:02 # +3
Это я к чему - а к тому, что размер исполняемого файла важен только для игрушек уровня сапера, в которых ресурсов раз два и обчелся. И если эти ресурсы, которые кстати плохо жмутся, в отличие от экзешника, весят около 30 метров, то всем пофиг на дополнительный метр, на которые может вырасти исполняемый файл пожатый инсталлятором...
gammaker 31.07.2012 17:06 # +1
Psionic 31.07.2012 18:36 # +1
gammaker 31.07.2012 18:52 # 0
Да и не ставил я особенно цель уложиться в 96 КБ. Просто стремлюсь сделать игру как можно меньше, особенно не жертвуя удобством разработки.
guest 31.07.2012 17:12 # +1
Это только тебе так кажется.
>>А малый процент XP'шников и линуксоидов скачают его(или Mono), если у них нет.
>>ко-ко-ко
Скачают. Ага. Иди-ка ты нахуй.
Вот сраная джаба есть везде, это да.
gammaker 31.07.2012 17:19 # 0
Больше половины пользователей пересели на семёрку. У многих XP'шников, даже мало разбирающихся в компьютерах, я видел установленный .NET Framework 2.0. А когда я допишу, XP'шников ещё меньше останется.
>Скачают. Ага.
Зато кроссплатформенно. У меня шарповые экзешники даже на телефоне через Mono запускаются без перекомпиляции.
guest 31.07.2012 17:25 # 0
Еще как!
http://govnokod.ru/10050
gammaker 31.07.2012 17:41 # 0
А так как даже на андроидах уже многие игры занимают по 500 МБ, то Mono за 100 МБ не так уж сложно скачать.
guest 31.07.2012 17:50 # +1
Но в спойлере написал про убогую джабу.
http://govnokod.ru/11487#comment149085
Но даже на ней иногда бывают серъезные траблы с "кроссплатформенностью".
По крайней мере в сане старались.
guest 31.07.2012 17:22 # +1
Первая сцылка в гугли
http://en.wikipedia.org/wiki/Usage_share_of_operating_systems
И это еще самый благоприятный прогноз, обычно XP оценивают около 40%.
Так что нахуй.
HaskellGovno 29.07.2012 08:27 # 0
gammaker 29.07.2012 10:58 # −1
HaskellGovno 29.07.2012 13:11 # +2
А это тебе чем не понравилось то? Все же меньше вероятность ошибки.
Да это:
gammaker 29.07.2012 15:27 # +1
HaskellGovno 29.07.2012 22:22 # +1
Почему бы это не применить?
gammaker 30.07.2012 16:04 # −3
Это конечно можно и использовать, но load_functions я вызываю достаточно редко, чтобы обойтись. А я предпочитаю не использовать шаблоны, когда они не очень нужны.