Изначальный план был таков: проработать где-нибудь месяца 2, накопить денег на переезд, потом связаться с одной геймдев-конторой из глубокого замкадья, где в кои веки требуется не трижды сертифицированный зубр, а стажер. После безуспешных попыток хоть куда-то устроиться за прошедший месяц плюнул, написал им, хотя денег и осталось только-только на доехать. Прислали тестовое задание - виндовый солюшн без всяких намеков на кроссплатформенность, хитрым способом берущий данные из lua и xml, хотя в основном там С++. В течение 3 часов ставил виртуалбокс и винду, разбирался, почему она периодически валится, поотключал всё ненужное, и теперь пялюсь на практически непонятные закорючки, как баран на новые ворота. Если бы тоже самое с нуля и по своему, м.б., даже сделал, а здесь - вообще не понятно, что откуда вызывается.

Интересно: то, что явления могут нравиться только на расстоянии - глобальное свойство мира, или индикатор того, что я занимаюсь не тем, чем нужно?

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

Для матриц используется glm - такой порт glsl на С++, для создания окна - SDL, есть файл с проектом для QtCreator(просто привык к этой IDE, хотя здесь без Qt).

Матрица создается следующей функцией:

mat4 mPerspective(float ratio, float zNear, float zFar, float fov)
{
    const float f = 1.0f/tan(radians(fov)/2.0f);
    mat4 mat = mat4(1.0f);
    mat[0][0]=f/ratio;
    mat[1][1]=f;
    mat[2][2]=(zFar+zNear)/(zFar-zNear);
    mat[2][3]=(2.0f*zFar*zNear)/(zNear-zFar);
    mat[3][2]=1.0f;
    mat[3][3]=0.0f;
    return mat;
}

После всех инициализаций, каждый кадр с матрицей модели происходит следующее:

void initWindow()
{
//...
    pers = mPerspective(ar,1.0f,100.0f,30.0f);
}
void drawScene()
{
    //...
    unifScale+=0.1f;
    vec4 rotVec(0.3f,unifScale,0.3f,1.0f);
    vec4 trVec(0.0f,0.0f,15.0f,1.0f);
    vec4 scVec(0.1f);
    tr = mat4(1.0f);
    tr =  mScale(scVec,tr);
    tr = mRotate(rotVec,tr);
    tr = mTransform(trVec,tr);
    tr*=pers;
    //...
}

!Ъ

Ъ:

OGLplus (oglplus) is a header only library which implements a thin object-oriented facade over the OpenGL (version 3 and higher) C-language API. It provides wrappers which automate the resource and object management and make the use of OpenGL in C++ safer and easier.

Features:

• Automatic resource management
• Type safety
• Error handling and diagnostic
• Interoperability with «basic» OpenGL
• Additional CG related classes

Похоже, и с SDL совместно можно будет использовать.

Хочется, чтобы и старые функции не были доступны, и новые автодополнялись. В glew(сейчас 1.6, 1.7 еще не пробовал) новые функции недоступны для подсветки синтаксиса и автодополнения, хотя, благодаря драйверу, и нормально собираются.

Так сейчас везде или я что-то неправильно настроил? Странно, что в gl3.h новые функции объявлены так:

GLAPI void APIENTRY glDrawArraysInstanced (GLenum mode, GLint first, GLsizei count, GLsizei primcount);

Еще нашел .spec файлы на openGL Regisrty, но не понял, что с ними делать. Хотя в них в основном типы и enum-ы объявляются.

SDL_Touch* touch = SDL_GetTouchIndex(i);
	if(!touch) printf("Touch %i/%i DNE\n",i,SDL_GetNumTouch());
	EventTouchData* data;
	data = (EventTouchData*)(touch->driverdata);
	if(data == NULL) {
	  printf("No driver data\n");
	  continue;
	}
	if(data->eventStream <= 0) 
	    printf("Error: Couldn't open stream\n");

Валится с ошибкой на этом куске при попытке сделать

SDL_Init(SDL_INIT_VIDEO|SDL_INIT_AUDIO)

На stackoverflow была такая же тема, но там заглохло на том, что один убунтоид сказал «УМВР». Если у кого стоит SDL 1.3(в нём прикрутили SDL_GLContext для нормальной работы с openGL выше второго, поэтому пришлось устанавливать его), попробуйте, пожалуйста, скомпилить с `sdl-config --cflags --libs`

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

int main(int argc, char **argv) {
    if(!SDL_Init(SDL_INIT_VIDEO|SDL_INIT_AUDIO))
    {
      printf("Error while initialising sdl\n");
      exit(-1);
    }
    SDL_Quit();
    return 0;
}

Попробовал сделать как здесь, но на первом же примере, в который добавил вывод значений, вылезла куча левого шлака из оперативки при вызове с параметрами «1.0,2.0,3.0»:

1
6.95318e-310
4.94066e-324
6.95318e-310
6.95318e-310
4.74303e-322
1.33789e-312
1.33797e-312
6.95318e-310
2.07432e-317
2
0

Стал искать вариант без него, потому что Qt Creator 2.2(как с последним не знаю, ставится пока) отображает выражение вида

int p=va_arg(perf,int);

Примерно как 'Человек в высоком замке', но во 2 мировой проиграли не все союзники, а СССР, и, возможно, Британия, но не США. Соответственно, коммунизм объявлен вселенским злом, а немцы - народом-спасителем человечества. По-моему, что-то такое тоже было.

Не первый раз, когда сталкиваюсь в шутерах. Кажется, на Linux SDL всё равно использует GLX для работы с графикой. Получается, фактическая разница - только в работе со звуком и устройствами ввода, или с графикой SDL добавляет некоторый оверхед? Что лучше использовать с точки зрения быстродействия, если делать что-то свое(для портируемости и простоты уже ясно, что SDL)?

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

Или на самом деле все везде одинаковое, и аббревиатура - просто добрая традиция?

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

#include <iostream>
#include <stdlib.h>
#include <GL/gl.h>
#include <SDL/SDL.h>
using namespace std;
void sdldie(string msg)
{
	cout<<msg<<": "<<SDL_GetError()<<endl;

}
int main(int argc,char* argv[])
{
	SDL_Window* mainwindow;
	SDL_GLContext maincontext;
	...

}

Пробовал делать в CodeBlocks и QtCreator - результат одинаков:

../sdl/main.cpp:15:2: ошибка: нет декларации ‘SDL_Window’ в этой области видимости ../sdl/main.cpp:15:14: ошибка: нет декларации ‘mainwindow’ в этой области видимости ../sdl/main.cpp:16:2: ошибка: нет декларации ‘SDL_GLContext’ в этой области видимости

Что удивительно, в SDL.h действительно нет SDL_Window. Это так API измениться успело или в другом заголовочном файле объявлено? Хотя здесь ссылаются на эти структуры

Сделал структуру, которую будет возвращать функция инициализации окна в glx:

struct contextResult
{
    Display dp;
    GLXContext ctx;
    Colormap cmap;
    Window win;
};

field ‘dp’ has incomplete type

Смотрю в Xlib.h и вижу:

/*
 * Display datatype maintaining display specific data.
 * The contents of this structure are implementation dependent.
 * A Display should be treated as opaque by application code.
 */
#ifndef XLIB_ILLEGAL_ACCESS
typedef struct _XDisplay Display;
#endif
typedef struct
#ifdef XLIB_ILLEGAL_ACCESS
_XDisplay
#endif
{
	XExtData *ext_data;	/* hook for extension to hang data */
	struct _XPrivate *private1;
	int fd;			/* Network socket. */
	int private2;
	int proto_major_version;/* major version of server's X protocol */
	int proto_minor_version;/* minor version of servers X protocol */
	char *vendor;		/* vendor of the server hardware */
        XID private3;
	XID private4;
	XID private5;
	int private6;
	XID (*resource_alloc)(	/* allocator function */
		struct _XDisplay*
	);
	int byte_order;		/* screen byte order, LSBFirst, MSBFirst */
	int bitmap_unit;	/* padding and data requirements */
	int bitmap_pad;		/* padding requirements on bitmaps */
	int bitmap_bit_order;	/* LeastSignificant or MostSignificant */
	int nformats;		/* number of pixmap formats in list */
	ScreenFormat *pixmap_format;	/* pixmap format list */
	int private8;
	int release;		/* release of the server */
	struct _XPrivate *private9, *private10;
	int qlen;		/* Length of input event queue */
	unsigned long last_request_read; /* seq number of last event read */
	unsigned long request;	/* sequence number of last request. */
	XPointer private11;
	XPointer private12;
	XPointer private13;
	XPointer private14;
	unsigned max_request_size; /* maximum number 32 bit words in request*/
	struct _XrmHashBucketRec *db;
	int (*private15)(
		struct _XDisplay*
		);
	char *display_name;	/* "host:display" string used on this connect*/
	int default_screen;	/* default screen for operations */
	int nscreens;		/* number of screens on this server*/
	Screen *screens;	/* pointer to list of screens */
	unsigned long motion_buffer;	/* size of motion buffer */
	unsigned long private16;
	int min_keycode;	/* minimum defined keycode */
	int max_keycode;	/* maximum defined keycode */
	XPointer private17;
	XPointer private18;
	int private19;
	char *xdefaults;	/* contents of defaults from server */
	/* there is more to this structure, but it is private to Xlib */
}
#ifdef XLIB_ILLEGAL_ACCESS
Display,
#endif
*_XPrivDisplay;

#include <GL/gl.h>
#include <GL/glx.h>
#include <GL/glext.h>
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/Xfuncproto.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

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

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

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

Понятно, что на будущее ничего нельзя делать без трудового договора, и вообще нужна жесткость и приспособленность к жизни, которой не хватает(видимо, надо в армию, в этом смысле хуже уже не будет), но что делать сейчас? Есть мизерная вероятность, что кому-то сделанное пригодится. Хотелось бы без километров переписываний что-то получить. Хотя, может, я накручиваю просто - завтра встречаемся, там будет яснее.

Хотя, возможно, и не только он, но больше ничего кододополняющего нет.

#include <iostream> подчеркивается зеленым и выводит сообщение: iostream: no such file or directory. Соответственно, и функции из std:: не дополняются, хотя всё нормально компилируется. Не смертельно, но неприятно. С удивлением обнаружил, что в системе действительно нет никакого iostream.h(по крайней мере, в /usr/include)

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

#include <stdio.h>
#include <GL/gl.h>
#include <GL/glx.h>
int main(int argc,char* argv[])
{
        int screenNumber;
        int *confNumber;
        Display *dpy = XOpenDisplay(NULL);
        GLXFBConfig *conf;
        screenNumber=DefaultScreen(dpy);
        conf = glXGetFBConfigs(dpy, screenNumber, confNumber);
        int *result;
        glXGetFBConfigAttrib(dpy,conf,GLX_TRANSPARENT_TYPE,result); 
        printf("%i\n",*result);
        XCloseDisplay(dpy);
}

(gdb) next
12              conf = glXGetFBConfigs(dpy, screenNumber, confNumber);
(gdb) next

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff792adb9 in glXGetFBConfigs () from //usr/lib64/opengl/nvidia/lib/libGL.so.1

Пытаюсь запустить примеры из главы superBible про glx, но всё сегфолтится. Сделал такой хелловорд.

Дело в нвидии или я что-то не так делаю?

В последнее время не дает покоя этот вопрос. И он не отвлеченный: читаю супербиблию openGL, но примерно с 3 главы примеры пришлось переделывать, чтобы заработали, а примерно с 8 они стали такими корявыми, что переделывать уже не получается: весь критически важный функционал упрятан автором в свою библиотеку, имитирующую фиксированный конвейер на openGL 3.2, и то, как она работает(пока только знаю, что геометрия рисуется через glDrawArrays и glDrawElements), будет раскрыто только в последней главе, что, конечно, добавляет интриги, но делает невозможной проверку на практике.

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

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

А еще витком ниже возник сабжевый вопрос: людям хорошо внутри и они начинают делать что-то, а не заполнять бессмысленность жизни просмотром толксов(значит, нужно фиксить баги «души») или люди начинают что-то делать и таким образом ангедония уходит?

Создал тему в толксах, где говорил, как крут арч, оказывается, рано радовался: примерно через 5 минут соединение обрывается(устройство ppp0 исчезает), хотя промежутки времени были разными.

Нужно, чтобы vpn-соединение поднималось при загрузке. Кажется подозрительным, что, если не вызывать dhclient, dhcpcd не получает адреса dns(/etc/resolv.conf остается только с закомментированными строчками).

Сама сеть поднимается скриптом pptp, записанным в DAEMONS в /etc/rc.conf:

[evg@myhost ~]$ cat /etc/rc.conf |grep DAEMONS
# DAEMONS
DAEMONS=(hwclock syslog-ng dbus network netfs @pptp crond @alsa kdm)

[evg@myhost ~]$ cat /etc/rc.d/pptp
#!/bin/bash
#dhclient && pon beeline && route del default 
dhclient && pptpsetup --create beeline --server vpn.internet.beeline.ru --username имя_пользователя@internet.beeline.ru --password пароль --start && route del default
route add default gw 10.50.7.1
route add default dev ppp0

Сейчас, когда сети нет, соединения следующие:

[evg@myhost ~]$ ifconfig 
eth0      Link encap:Ethernet  HWaddr 00:1D:7D:9E:6D:7F  
          inet addr:10.50.7.207  Bcast:10.50.7.255  Mask:255.255.255.0
          inet6 addr: fe80::21d:7dff:fe9e:6d7f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:81169 errors:0 dropped:0 overruns:0 frame:0
          TX packets:38240 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:111036235 (105.8 Mb)  TX bytes:4525046 (4.3 Mb)
          Interrupt:41 Base address:0x6000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:202 errors:0 dropped:0 overruns:0 frame:0
          TX packets:202 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:12336 (12.0 Kb)  TX bytes:12336 (12.0 Kb)

[evg@myhost ~]$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.50.7.1       0.0.0.0         UG    0      0        0 eth0
10.50.7.0       0.0.0.0         255.255.255.0   U     0      0        0 eth0
89.179.76.154   10.50.7.1       255.255.255.255 UGH   0      0        0 eth0

После выполнения скрипта:

[root@myhost ~]$/etc/rc.d/pptp                                                    
Using interface ppp0
Connect: ppp0 <--> /dev/pts/0       
CHAP authentication succeeded      
CHAP authentication succeeded       
local  IP address 78.106.240.10
remote IP address 89.179.76.153 
[root@myhost evg]# ifconfig 
eth0      Link encap:Ethernet  HWaddr 00:1D:7D:9E:6D:7F  
          inet addr:10.50.7.207  Bcast:10.50.7.255  Mask:255.255.255.0
          inet6 addr: fe80::21d:7dff:fe9e:6d7f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:193305 errors:0 dropped:0 overruns:0 frame:0
          TX packets:98038 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:270731309 (258.1 Mb)  TX bytes:10916602 (10.4 Mb)
          Interrupt:41 Base address:0x6000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:328 errors:0 dropped:0 overruns:0 frame:0
          TX packets:328 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:20064 (19.5 Kb)  TX bytes:20064 (19.5 Kb)

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:2.92.71.32  P-t-P:89.179.76.156  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1460  Metric:1
          RX packets:52674 errors:0 dropped:0 overruns:0 frame:0
          TX packets:27198 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:70869327 (67.5 Mb)  TX bytes:1710199 (1.6 Mb)
[root@myhost evg]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
0.0.0.0         10.50.7.1       0.0.0.0         UG    0      0        0 eth0
10.50.7.0       0.0.0.0         255.255.255.0   U     0      0        0 eth0
89.179.76.156   10.50.7.1       255.255.255.255 UGH   0      0        0 eth0
89.179.76.156   0.0.0.0         255.255.255.255 UH    0      0        0 ppp0

[root@myhost evg]# cat /etc/ppp/peers/beeline 
# written by pptpsetup
pty "pptp vpn.internet.beeline.ru --nolaunchpppd"
lock
noauth
nobsdcomp
nodeflate
name имя_пользователя@internet.beeline.ru
remotename beeline
ipparam beeline

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

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

Было принято решение снести то, что есть, и поставить что-нибуть человеческое(но второй раз после своего ноута ставить генту было как-то лень). Сначала попробовал поставить xubuntu 10.10 - юнити туда, слава богу, еще не добрался, но скрипт по прежнему не хотел работать на выходе из ждущего режима(даже из rc.local почему-то перестал).

После был LMDE, но дефолтная система инициализации и отсутствие возможности смешивать ветки(как ~arch и arch в генте или ppa в убунте) показались какими-то совсем бестолковыми. Когда при установке какого-то расширения хрома выяснилось, что версия больно стара, а обновить её, не переходя при этом на unstable, не выйдет(возможно, я что-то упустил?), решил попробовать то, на что давно облизывался - Arch.

Если бы идеальный дистрибутив существовал, имхо, это был бы арч с use-флагами. Очень понравились DAEMONS в rc.conf - можно поместить в rc.d вообще любой скрипт, не думая об init-стандартах, и теперь и после спящего режима поднимается. Конечно, в генте есть eix, но pacman по скорости работы(в частности, поиска пакетов) не идет ни в какое сравнение с emerge. А самое главное - в общей сложности на установку ушло не больше 4 часов. Теперь осталось только ему virtualBox поставить: за мое отсутствие в городе он попал на курсы к мелкомягким:(

Let’s take a look at our next example program, DiffuseLight. This program demonstrates a simple diffuse lighting shader on a blue sphere. It uses a point light source so you can also see how we determine this in a shader. Of course using a directional light source would be simpler since we’d already supply this vector, but we, as they say, leave that as an exercise for the reader. Listing 6.7 shows the complete DiffuseLight.vp vertex shader.

В openGL Superbible описывается шейдер диффузного затенения. На каждом проходе вычисляется вектор направления света по отношению к данной вершине. Как я понял, чтобы сделать источник света направленным, нужно вычислять вектор источника независимо от текущей вершины. Сделал нормализацию только самого вектора положения источника, но визуально это ничем не отличалось от первого варианта. Или нужно было вне шейдера взять среднюю точку сферы и отнять её от положения источника?

...
uniform vec4	diffuseColor;	
uniform vec3	vLightPosition;
uniform mat4	mvpMatrix;
uniform mat4	mvMatrix;
uniform mat3	normalMatrix;

// Color to fragment program
smooth out vec4 vVaryingColor;

void main(void) 
    { 
    // Get surface normal in eye coordinates
    vec3 vEyeNormal = normalMatrix * vNormal;

    // Get vertex position in eye coordinates
    vec4 vPosition4 = mvMatrix * vVertex;
    vec3 vPosition3 = vPosition4.xyz / vPosition4.w;

    // Get vector to light source
    vec3 vLightDir = normalize(vLightPosition - vPosition3);
//я сделал vec3 vLightDir = normalize(vLightPosition);
...

Пытаюсь подсоединиться к семерке с gentoo.

localhost torrents # mount -t cifs -o user=user%password //192.168.10.2/Users /mnt/wm
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

localhost torrents # smbclient //192.168.10.2/Users -U user%password
Domain=[WORKGROUP] OS=[Windows 7 Ultimate 7601 Service Pack 1] Server=[Windows 7 Ultimate 6.1]
smb: \>