Кодерский уголок

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

 

MSVC2013 CE при сборке решения пишет:

https://msdn.microsoft.com/en-us/library/b0084kay(v=vs.120).aspx

Вроде понимаю, что речь идет о версии используемого языка и стандарте C99, а что с этим делать в MSVC - не ясно.

Ключ /Za (Properties->C/C++->Language->Disable Language Extensions->Yes/Za) ставил, начинает сыпать кучу ошибок, встретив struct.

Добавить макрос в Properties->C/C++->Preprocessor?

 

Попробуй выбрать другой Platform toolset в свойствах проекта, вкладка general. Выбери xp чё-то там. Ваще, там можно даже toolset от 2008ой вижуалки выбрать. Это у меня, видать, с какой-то игрой поставился redistributable package от vs2008.

 

@Steel Rat, скорее всего, я изначально что-то делаю не так.

Беру с github'а архив .zip, заявленный как "тяжелая" модификация движка (оригинального исходного кода). Модификация осуществлялась заменой вызовов ARB на вызовы GLSL.

Не нахожу там ни .sln, ни .proj (просто набор папок и файлов h. и .cpp).
CMake-ов тоже нет.

Перемещаю всё это в оригинальный исходный код с заменой файлов.

Пытаюсь скомпилировать через имеющийся в оригинальных исходниках .sln.

Получаю эту ошибку.

Вопрос - а вообще в каких случаях используется такая сборка (master), без sln?
Может, что-то изначально предназначенное не для компиляции под MSVC?
(вижу в коде UNIXOS, OSX).

И как работать с этим в MSVC?

 

это надо смотреть в документации к проекту на гитхабе.

 

Эм... што?

 

это - https://ru.wikipedia.org/wiki/OpenGL_Shading_Language

ну извращения замаскированные под прогресс и движение к вулкану.

 

@Bato-San, што? [2]
«Вызовы ARB» — это со стороны ЦП. «Вызовы GLSL» — это встроенные в видеокарту инструкции или стандартные их последовательности (как, например, refract).
Более того, 1.50 — это, извините меня, даже не OGL 4.x, так что ни о каком вулкане в 1.50 речи идти не может.

 

@hidefromkgb, скачай этот движок лучше, да посмотри сам, чем всем "штокать".
Насколько я понял - пытаются переложить вычисления с проца на видеокарту. Про вулкан - сарказм.

 

Без паники! Я, разобравшись в проблеме, потом свои вопросы вообще без смеха читать не могу.

Но вы даёте мне бесценные крохи информации (ключевые точки, слова и пр.), по которым я уже выхожу на суть.

Так что - спасибо

--- добавлено 29 окт 2015, предыдущее сообщение размещено: 29 окт 2015 ---

Короче, ARB 1.0 -> OGL 3.2.

Зато опенсорс-с, да-с.

 

Нет.

Когда говорят "шейдеры на ассемблере", конечно же, никто не подразумевает x86-ассемблер для центрального процессора.

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


Он был стандартизирован консорциумом ARB - обычно говорят "ARB assembly shaders".
Но есть и варианты от производителей видеокарт.

И весьма устарел - актуален был во времена начиная с GeForce 3 до GeForce 5-й серии (в ней появился GLSL, но работал ещё не очень хорошо).


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



@Bato-San, то есть - как были вычисления на видеокарте, так они и остались.

Заменяют - ибо сейчас многие программисты даже не знают как эти самые ARB шойдеры выглядят



GLSL весьма гибкая вещь - можно сделать отличный графоний:

примеров не очень много - обычно применяется в мульти-платформенных движках (Unity, Unreal Engine, или, например, бенчмарк Unigine)


вот например, Unreal Engine 4 на Linux использует OpenGL 3.3 (наверно, шейдеры GLSL тоже версии 3.3 ибо ввели одинаковую нумерацию):

а ещё тысячи игр для Android - там вообще без GLSL не обходится дело )

 

Во, кому-то не лень было объяснять. @daemolisher, благодарствую мил человек.
Но что под «ARB» имелось в виду именно arb(v|f)p1.0, понял только после того, как @Kristobal Hozevich Hunta сам сказал. До этого думал, что просто функции ARB-расширений вызываются.

 

Пожалуйста, помогите!

Я пытаюсь в очередной раз что-то сваять на QBASIC. На этот раз - бродилка. Элементарнейшая. Но у меня такая проблема!
В первом варианте игры я просто сделал считывание с клавиатуры с помощью INPUT$(1).

SCREEN 1: KEY OFF: RANDOMIZE TIMER: CLS

GOSUB game: END

game:

GOSUB prepare

start:
GOSUB drawing
GOSUB move
GOTO start

RETURN

prepare:

CLS

DIM world(1 TO 10, 1 TO 10) AS INTEGER

FOR x = 1 TO 10
FOR y = 1 TO 10
LET world(x, y) = 0
NEXT y
NEXT x

LET x = 0
LET y = 0

LET xp = 1
LET yp = 1

LET world(xp, yp) = 1

RETURN

drawing:

CLS

FOR x = 1 TO 10
FOR y = 1 TO 10
IF world(x, y) = 0 THEN LOCATE x, y: PRINT "+"
IF world(x, y) = 1 THEN LOCATE x, y: PRINT "Y"
NEXT y
NEXT x

LET x = 0
LET y = 0

RETURN

move:

keyin$ = INPUT$(1)

IF LCASE$(keyin$) = "q" THEN END

IF LCASE$(keyin$) = "w" THEN
LET x = xp + 1
IF x < 1 OR x > 10 THEN LET x = 0: RETURN
IF world(x, yp) = 2 THEN LET x = 0: RETURN
LET x = 0
LET world(xp, yp) = 0
LET xp = xp + 1
LET world(xp, yp) = 1
END IF

IF LCASE$(keyin$) = "s" THEN
LET x = xp - 1
IF x < 1 OR x > 10 THEN LET x = 0: RETURN
IF world(x, yp) = 2 THEN LET x = 0: RETURN
LET x = 0
LET world(xp, yp) = 0
LET xp = xp - 1
LET world(xp, yp) = 1
END IF

IF LCASE$(keyin$) = "d" THEN
LET y = yp + 1
IF y < 1 OR y > 10 THEN LET y = 0: RETURN
IF world(xp, y) = 2 THEN LET y = 0: RETURN
LET y = 0
LET world(xp, yp) = 0
LET yp = yp + 1
LET world(xp, yp) = 1
END IF

IF LCASE$(keyin$) = "a" THEN
LET y = yp - 1
IF y < 1 OR y > 10 THEN LET y = 0: RETURN
IF world(xp, y) = 2 THEN LET y = 0: RETURN
LET y = 0
LET world(xp, yp) = 0
LET yp = yp - 1
LET world(xp, yp) = 1
END IF

RETURN

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


game:

GOSUB prepare

start:
DO
keyin$=INKEY$
GOSUB drawing
GOSUB move
GOTO start
LOOP UNTIL keyin$<>INKEY$
RETURN

, а в подпрограмме move: убрать строчку keyin$ = INPUT$(1).

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

Я ничего не понял.

Обьясните, пожалуйста, что со мной не так!

 

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

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

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

 

Спасибо, Bato-San!
Но к тому времени, как вы мне ответили, я уже самостоятельно допёр, что не стоит каждый раз отрисовывать поле. Придумал простенький буфер в 2 переменные.

На самом деле, это единственный способ, который удался и был доказан моими экспериментами.

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

А за похвалу моей альтернативной логике и программированию за гранью добра и зла спасибо.

--- добавлено 1 янв 2016, предыдущее сообщение размещено: 1 янв 2016 ---

Кстати, если надо, могу окончательную версию выложить.

(Блин, не льсти себе, кому она нужна...)

 

148 строк кода для детской поделки и отсутствие желания переделать строк в 10 - 20... не комильфо. Всё же рекомендую, прежде чем строчить что то, продумать полностью алгоритм, изучить возможности языка и аппаратуры, подумать о минимальной длине кода и максимальном быстродействии.

 

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

Но всё это разбивается о четыре чертовых камня :

ЛЕНЬ

ЖЕЛАНИЕ ПИСАТЬ БЫСТРО И СРАЗУ

НЕУМЕНИЕ ПРОГРАММИРОВАТЬ

ЗАВЫШЕННОЕ ЧСВ

--- добавлено 1 янв 2016, предыдущее сообщение размещено: 1 янв 2016 ---

Кстати, обьясните пожалуйста, как это дело можно перебрать в 20 строк?

 

@New_Old_Gamer, ну мне лень за день дважды читать лекцию на одну и туже тему, поэтому я кратко скажу: выбрось нафиг повторяющиеся фрагменты программы, убери подпрограммы вообще и пиши простые IF ... THEN...

ЗЫ. Ну хорошо хоть самокритика у тебя на должном уровне.

 

Спасибо большое!

--- добавлено 1 янв 2016, предыдущее сообщение размещено: 1 янв 2016 ---

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

 

Нэ надо.
Возможно, когда @Bato-San говорил о минимальной длине кода, он вовсе не подразумевал попытки умещать весь код в 20 строчек.

Скорее, следует избегать вот такого:

- этот участок повторяется 4 раза.

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

Возможно, этот код стоит переписать в виде функции (суть оптимизации на примере Python)

Примеры, использования функций в QBasic:
http://progopedia.ru/implementation/qbasic/
https://en.wikibooks.org/wiki/QBasic/Subroutines_and_Functions#Declaring_a_function


И ещё:
Что будет если игрок нажмёт сразу несколько клавиш?