purebasic.info

PureBasic forum
Текущее время: Чт ноя 15, 2018 1:29 am

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 27 ]  На страницу Пред.  1, 2
Автор Сообщение
 Заголовок сообщения: Re: Организация программного кода
СообщениеДобавлено: Пт июн 15, 2018 6:59 am 
Не в сети
профессор

Зарегистрирован: Чт фев 09, 2017 10:37 am
Сообщений: 235
Благодарил (а): 22 раз.
Поблагодарили: 33 раз.
Пункты репутации: 0
fil@tov писал(а):
Мне понравился вариант с созданием проекта.
В справке есть "Управление проектами".


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Организация программного кода
СообщениеДобавлено: Пт июн 15, 2018 9:51 am 
Не в сети
доцент

Зарегистрирован: Пн мар 30, 2015 5:48 pm
Сообщений: 51
Благодарил (а): 35 раз.
Поблагодарили: 0 раз.
Пункты репутации: 0
fil@tov писал(а):
глобальные переменные

Пётр писал(а):
Их в программе должно быть как можно меньше.


Почему глобальных переменных в программе должно быть как можно меньше? Чтобы меньше оперативной памяти задействовать?


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Организация программного кода
СообщениеДобавлено: Пт июн 15, 2018 10:10 am 
Не в сети
МОДЕРАТОР
Аватар пользователя

Зарегистрирован: Пн апр 09, 2007 4:53 pm
Сообщений: 11325
Благодарил (а): 4 раз.
Поблагодарили: 440 раз.
Во многих случаях вместо глобальных переменных можно передавать данные через аргументы процедуры.
Глобальные переменные нужно использовать в тех случаях когда это действительно необходимо.

_________________
Компьютер позволяет решать все те проблемы, которые до его изобретения не существовали. :) :)


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Организация программного кода
СообщениеДобавлено: Пт июн 15, 2018 10:15 am 
Не в сети
док
Аватар пользователя

Зарегистрирован: Вт ноя 22, 2016 7:59 am
Сообщений: 77
Откуда: Россия/Пятигорск
Благодарил (а): 0 раз.
Поблагодарили: 15 раз.
Пункты репутации: 0
Глобальные переменные рекомендуется использовать как можно реже, чтобы избежать возможных конфликтов имен.
Например, если будет существовать глобальная переменная Name, и локальная переменная с таким-же именем.
Таких конфликтов можно избежать, если следовать определенному стилю именования переменных (например gИмяПеременной - для глобальных, а mИмяПеременной - для локальных). Но в этом случае при использовании сторонних модулей нет гарантии, что авторы этих модулей следуют тому же стилю).
Поэтому по возможности лучше пользоваться локальными переменными.


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Организация программного кода
СообщениеДобавлено: Ср сен 05, 2018 4:14 pm 
Не в сети
профессор

Зарегистрирован: Пт фев 20, 2009 12:57 pm
Сообщений: 1706
Откуда: Алматы
Благодарил (а): 16 раз.
Поблагодарили: 46 раз.
Пункты репутации: 5
понадобилось выдирать из результатов работы procedurereturn два значения. да, можно склеивать два в одно, после опять расклеивать.

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

вот собственно вопрос - как это делается?

Код:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Procedure.a Test(par1.a, par2.a, par3.a)
 
  ret.a
 
  if par1 = par2
    ret = 1
    par3 = 123
  endif
 
procedurereturn ret
endprocedure
 
if Test(1, 1, par3)
  debug par3
endif
 
 



Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Организация программного кода
СообщениеДобавлено: Ср сен 05, 2018 4:32 pm 
Не в сети
МОДЕРАТОР
Аватар пользователя

Зарегистрирован: Пн апр 09, 2007 4:53 pm
Сообщений: 11325
Благодарил (а): 4 раз.
Поблагодарили: 440 раз.
Создаешь структуру и передаешь ее процедуре по указателю.
Код:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Structure x
  x.a
  y.f
  z.s
  List l.i()
EndStructure
 
Procedure Tst(*x.x)
  If *x
    *x\x = 1
    *x\y = 2.5
    *x\z = "1234"
    If AddElement(*x\l())
      *x\l()=10
    EndIf
  EndIf
EndProcedure
 
s.x
Tst(s)
 
Debug s\x
Debug s\y
Debug s\z
 
ForEach s\l()
  Debug s\l()
Next

Но можно ограничится списком (или массивом и т. д.). Вариантов много.
Код:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Procedure Tst(List l.i())
 
  If AddElement(l())
    l()=10
  EndIf
 
  If AddElement(l())
    l()=20
  EndIf
 
EndProcedure
 
NewList x.i()
Tst(x())
 
ForEach x()
  Debug x()
Next


_________________
Компьютер позволяет решать все те проблемы, которые до его изобретения не существовали. :) :)


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Организация программного кода
СообщениеДобавлено: Вт сен 25, 2018 10:04 pm 
Не в сети
профессор

Зарегистрирован: Пт фев 20, 2009 12:57 pm
Сообщений: 1706
Откуда: Алматы
Благодарил (а): 16 раз.
Поблагодарили: 46 раз.
Пункты репутации: 5
с экранами закончил. почти все что хотел туда доделал и вроде работает. товарищ говорит доделывай теперь и редактор графики юнитов. система эта осталась в подвешенном состоянии... я все ждал может стукнет вдохновение и родится какая революционная идея... но нет. не возникла. не помню, по моему я такую тему уже создавал. на всякий еще раз поплачу в желетку.

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

Изображение

файл первый - include.asm - главный файл. в нем в принципе касаемо юнитов ничего не изменяется.

файл второй - файл конкретного юнита, в данном случае unita carryall carrall.bin - в нем может быть изменен адрес и тип спрайта. от типа спрайта зависит то - сколько строчек надо читать из следующего файла. например есть такой тип где всего 3 положения юнита. 0 градусов - мордой вверх, 45 - по диагонали и 90 - боком. значит 3 строчки всего. бывают и другие типы с 5 положениями, там графика более плавная так как промежуточные градусы добавлены типа 23 и 67. бывают 16 положений по кругу... и тому подобное. то есть файл юнита править проблем не составит.

третий - файл 2_main_sprites_ptrs.asm - в нем лист ссылок по номерам. по этим номерам, полученным из предыдущего файла игра ищет ссылки дальше. как например этот самый carryall 3 положения, то есть три строки:
Цитата:
dc.l NO_LOAD_GFX
dc.l carry_spr_cfg1|AIR_UNIT_SPR
dc.l NO_LOAD_GFX
dc.l carry_spr_cfg2|AIR_UNIT_SPR
dc.l NO_LOAD_GFX
dc.l carry_spr_cfg3|AIR_UNIT_SPR
dc.l HAVE_SPR
dc.l carryharv_spr_cfg1|AIR_UNIT_SPR
dc.l HAVE_SPR
dc.l carryharv_spr_cfg2|AIR_UNIT_SPR
dc.l HAVE_SPR
dc.l carryharv_spr_cfg3|AIR_UNIT_SPR

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

четвертый файл - зная адреса carry_spr_cfg1, carry_spr_cfg2, carry_spr_cfg3 - прогоняем по списку все файлы конфигурации. хоть в одном да попадутся эти строчки. и такой находится в файле 8_carry_spr_cfg.asm - в нем carry_spr_cfg1 соответствуют две записи:
Цитата:
carry_spr_cfg1:
dc.w 1
dc.w $20, $20, $FFF0, spr2x4, crr_t1|HVMirr, $FFF0 ; клеит из двух половинок
dc.w $20, $20, $FFF0, spr2x4, crr_t1|VMirr, $0

таким образом получена следующая метка crr_t1.

пятый файл - 5_math_sprites_cfgs.asm - в нем происходит подсчет математики для получения количества тайлов, которые потом игра будет записывать в память приставки, и видимо расчет их местоположения в роме игры, чтобы приставка знала откуда их читать. в нем метке crr_t1 соответствует метка caryall_spr1
Цитата:
crr_t1 equ (caryall_spr1-misc_spr2)/32+base3


шестой файл - 4_path_sprites_cfgs.asm - в нем указаны пути до физических файлов графики юнитов и их метки.
Цитата:
caryall_spr1:
incbin gfx\sprites_gfx\carryall_spr1.smd




и это, думаете, весь геморой? э неее :) есть особые случаи сохранения изображения. например для этого carryall указан типоразмер 2х4. то есть кажется что 8 тайлов... а нифига :) 7 на самом деле. восьмой пустой и при правильном развороте изображения, а пустой тайл должен быть внизу справа - он не влияет на это самое изображение и в итоге можно на этом сэкономить. но такое не везде. есть если написано 2х4, то строго должно быть 8 тайлов. если меньше - поплывет вся графика. там я еще не уловил в чем разница, сам алгоритм просчета размера сохранения то сделал. но, как оказалось, он может применяться не везде. это еще надо выяснить.


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Организация программного кода
СообщениеДобавлено: Пн окт 15, 2018 1:46 am 
Не в сети
профессор

Зарегистрирован: Пт фев 20, 2009 12:57 pm
Сообщений: 1706
Откуда: Алматы
Благодарил (а): 16 раз.
Поблагодарили: 46 раз.
Пункты репутации: 5
Пётр, еще вопрос. лишь в последнее время открыл для себя америку с CompilerIf #PB_Compiler_IsMainFile и это дико удобно в большом проекте отлаживать какие-то отдельные окна или функции или еще чего, чтоб весь проект каждый раз не собирать. а тут, значит, прикручивал простеньку защиту от копирования. товарищ просто раздолбай. ему хватает ума нашу секретную программу давать кому не попадя. вот, значит, часть кода делает эти всякие проверки и программа закрывается. приходится эту часть все время закомменчивать, чтоб что-то изменять в коде и тестировать. а обратно расскоменчивать иной раз забываю. то есть могу случайно ему отдать "не защищенную" версию. нет ли какого-то условия в PB, типа того замечательного CompilerIf, но для подобного случая? чтобы если это PB запускает ехе файл - проверка не стартовала. если ехе уже собран и запускаешь сам своими руками - тогда чтоб проверка проходила.


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Организация программного кода
СообщениеДобавлено: Пн окт 15, 2018 8:01 am 
Не в сети
профессор

Зарегистрирован: Чт сен 22, 2011 6:21 pm
Сообщений: 271
Благодарил (а): 36 раз.
Поблагодарили: 27 раз.
Пункты репутации: 0
1) Надо помнить что CompilerIf принимает только константы.
2) Исходя из вашей задачи больше всего подойдет: (#PB_Compiler_Debugger : равна 1, если включен отладчик, иначе равна 0.)
Вот список встроенных констант:
Код:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
  #PB_Compiler_OS : Позволяет узнать, на какой платформе работает компилятор. Может быть одно из следующих значений :
    #PB_OS_Windows : Компилятор работает на Windows
    #PB_OS_Linux   : Компилятор работает на Linux
    #PB_OS_MacOS   : Компилятор работает на Mac OS X
 
  #PB_Compiler_Processor :  определяет тип процессора. Может быть одно из следующих значений :
    #PB_Processor_x86     : процессор архитектуры x86 (также называемой IA-32 или x86-32)
    #PB_Processor_x64     : процессор архитектуры x86-64 (также называемой x64, AMD64 или Intel64)
 
  #PB_Compiler_ExecutableFormat : Определяет формат исполняемых файлов. Может быть одно из следующих значений :
    #PB_Compiler_Executable : обычный исполняемый файл (EXE)
    #PB_Compiler_Console    : консольный исполняемый файл (имеет эффект только на Windows, на других действует как обычный исполняемый файл)
    #PB_Compiler_DLL        : совместно используемый DLL (dynlib на MacOS X и общем объекте на Linux)
 
  #PB_Compiler_Date     : Текущая дата, во время компиляции, в формате даты PureBasic.
  #PB_Compiler_File     : Полный путь и имя компилируемого файла, полезно для отладки.
  #PB_Compiler_FilePath : Полный путь компилируемого файла, полезно для  отладки.
  #PB_Compiler_Filename : имя скомпилированного файла (без пути) файла, полезно для отладки.
  #PB_Compiler_Line     : номер строки компилируемого файла, полезно для отладки.
  #PB_Compiler_Procedure: название текущей процедуры, если строка находится внутри процедуры.
  #PB_Compiler_Module   : текущее имя модуля, если строка внутри  модуля.
  #PB_Compiler_Version  : версия компилятора, целое '420' для версии 4.20.
  #PB_Compiler_Home     : Полный путь директории PureBasic, может быть полезен чтобы найти включаемые файлы
  #PB_Compiler_Debugger : равна 1, если включен отладчик, иначе равна 0.
                          Когда исполняемый файл уже создан, отладчик всегда отключается (эта константа будет равна 0)
  #PB_Compiler_Thread   : Равна 1 если выполняемый файл компилируется в потоко-безопасном режиме, иначе равна 0.
  #PB_Compiler_Unicode  : Равна 1 если выполняемый файл компилируется в режиме уникода, иначе равно 0.
  #PB_Compiler_LineNumbering : равно 1, если исполняемый файл скомпилирован с поддержкой OnError line numbering, иначе равно 0.
  #PB_Compiler_InlineAssembly: равно 1, если исполняемый файл скомпилирован с поддержкой Встроенного x86 ASM, иначе равно 0.
  #PB_Compiler_EnableExplicit: равно 1, если исполняемый файл скомпилирован с Включенным явным определением переменных, иначе равно 0.
  #PB_Compiler_IsMainFile    : равно 1, если откомпилированный файл является основным файлов, иначе равно 0.
  #PB_Compiler_IsIncludeFile : равно 1, если откомпилированный файл является included в другой файл, иначе равно 0.
 


зы. все вышесказанное есть в справке...


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Организация программного кода
СообщениеДобавлено: Пн окт 15, 2018 11:04 am 
Не в сети
МОДЕРАТОР
Аватар пользователя

Зарегистрирован: Пн апр 09, 2007 4:53 pm
Сообщений: 11325
Благодарил (а): 4 раз.
Поблагодарили: 440 раз.
SereZa писал(а):
если это PB запускает ехе файл - проверка не стартовала. если ехе уже собран и запускаешь сам своими руками - тогда чтоб проверка проходила.
В настройках компилятора, на вкладке "Константы" нужно поставить галочку в #PB_Editor_CreateExecutable и использовать ее в CompilerIf.

_________________
Компьютер позволяет решать все те проблемы, которые до его изобретения не существовали. :) :)


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Организация программного кода
СообщениеДобавлено: Вт окт 23, 2018 3:07 pm 
Не в сети
профессор

Зарегистрирован: Пт фев 20, 2009 12:57 pm
Сообщений: 1706
Откуда: Алматы
Благодарил (а): 16 раз.
Поблагодарили: 46 раз.
Пункты репутации: 5
а как можно в функции предусмотреть не ограниченное количество параметров? у меня лист в клетку, в который выводится изображение из нескольких кубиков. сами кубики имеют свои номера индивидуальные. вот хочу что-то типа:
фунция(типоразмер, х, y, 10, 11, 23, 45,...)
там типа слева направо перечисление номеров согласно типоразмеру. скажем типоразмер 2х2, значит левый верхний, правый верхний, левый нижний, правый нижний. то есть получается 4 параметра. оп... тьфу... не пойдет. в одном случае у меня 3х3, но кубиков 8. левый нижний там пустой... значит не пойдет такое :)


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Организация программного кода
СообщениеДобавлено: Вт окт 23, 2018 4:58 pm 
Не в сети
МОДЕРАТОР
Аватар пользователя

Зарегистрирован: Пн апр 09, 2007 4:53 pm
Сообщений: 11325
Благодарил (а): 4 раз.
Поблагодарили: 440 раз.
Код:
1
2
3
Procedure Test(List x())
 
EndProcedure

Заполняй список и передавай в процедуру.

_________________
Компьютер позволяет решать все те проблемы, которые до его изобретения не существовали. :) :)


Вернуться наверх
 Профиль  
 
Показать сообщения за:  Сортировать по:  
Начать новую тему Ответить на тему  [ Сообщений: 27 ]  На страницу Пред.  1, 2

Часовой пояс: UTC + 3 часа


Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 7


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

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group (блог о phpBB)
Сборка создана CMSart Studio
Русская поддержка phpBB