LINUX.ORG.RU

сделать загрузочный экран?

 , , , ,


0

4

Цель показывать загрузочный(приветствующий с логотипом игры) экран с прогрессбаром, пока подгружаются остальные ресурсы. Проект Demo, основные ресурсы находятся в папке Demo (исходники),https://www.github.com/Beginerok/Tropic-Island . Вообщем все что нужно делается функциями Scene1_->LoadWelcome() -загружаются ресурсы для экрана приветствия, и Scene1_->ShowWelcome() для показа в файле Game.cpp. Нужно как-то отбражать сначала Scene1_->ShowWelcome(), а после этого Scene1_->ShowDrum() когда загрузятся остальные. Вот и с минимальными правками, std::thread не помог

Ответ на: комментарий от Gremlin_

Потому что у тебя вряд ли будет такое количество ресурсов, что сплеш будет оправдан.

Отвечаю на удалённое:

Это, конечно, хорошо, но совершенно не убирает помойку, которая царит в твоём репозитории. Что за pdf/docx/pptx? Почему разные проекты лежат в одном репозитории?

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

XMs ★★★★★ ()

Что за придурь такая, писать ответ, потом удалять его, и писать другой?
Ты думаешь, мы не видим твои удалённые ответы?

anonymous ()

Просто оставлю это здесь:
Допущен к защите
Зав. кафедрой ______________С.Д. Кургалин, д.ф.- м.н., профессор __.__.20__
Обучающийся _______________Е.Д. Петряев, 4 курс, д/о
Руководитель _______________ А.Ф. Клинских, д.ф.- м.н., профессор

anonymous ()
Ответ на: комментарий от Gremlin_

Не могу, их там больше, чем кода.

Короче, сделай НОВЫЙ проект (в отдельном репозитории!!!), где у тебя будет два треда. Первый будет бесконечно выводить значение глобальной переменной, второй будет читать что-то вроде /dev/urandom и писать в эту переменную количество прочитанных байт. Как сделаешь — притащи, заценим. Если сделаешь правильно, то и ОП-проблему будешь знать, как решить

XMs ★★★★★ ()

Минутка обязательного кодревью. Хедер для Game.cpp, лицо можно сказать проЭкта...

#include "Scene1.h" //если ниже все равно исп. указатель, можно инклудить в cpp (см. "forward declaration"), ускоряет сборку когда проект подрастет

//#include "Window.h"
class Game
{
public:              // норм, рили? :) 
Scene1 *Scene1_;     // подчеркивание для прайвитов в паблике... зойчем? Или зойчем приватные поля класса в секции паблик?
slackwarrior ★★★★★ ()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от Gremlin_

При том, что разделение на private/protected/public — это разграничение ролей. Это возможность сделать инкапсуляцию. Это логика, в конце концов

XMs ★★★★★ ()
Последнее исправление: XMs (всего исправлений: 1)
Ответ на: комментарий от Gremlin_

Да причем тут стороны :) Это с порога меня встречает в коде, который называется «с++». Публичные поля класса :))) Шел 2019 год.

П.С. При этом они используют в именах подчеркивание, которое должно означать что они приватные, так что непонятно, это намеренье автора или нет (ну было раньше «норм» делать публичные поля, но их при этом именовали так что было понятно — «автору норм, и он именно это имел в виду». А тут они в паблике, но с подчеркиванием.

slackwarrior ★★★★★ ()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от XMs

Как сделаешь — притащи, заценим.

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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

Ну можно посоветовать "«море эффектов» Мейерса — про 35 и больше путей улучшения кода (и еще больше эффектов) чтоб хотя бы код стало можно читать. А так-то дизаен и эволюцию надо чтить :)

slackwarrior ★★★★★ ()
Ответ на: комментарий от i-rinat

Затем что «наследовать» нужно не все подряд, а только по делу. Например городить иерархии в 2019-м не обязательно. А лучше вообще ТСу почитать про компонентную модель, предпочтение композиции наследованию и ресурсы по конструированию игродвижков. Например Может по «базовым понятиям» вопросов будет меньше, и делать «сразу примерно по уму», чем бороться со своим же кодом.

slackwarrior ★★★★★ ()
Ответ на: комментарий от Gremlin_

Минутка обязательного развития


typedef GLvoid void__;

void__ Exit(); //ну прежде чем такое писать можно было бы и разузнать зачем в openGL GLvoid, 

и почему эта замена тут, в пользовательском коде, не имеет смысла, если функция не возвращает указатель GLvoid* для передачи в какой-то вызов OpenGL или этот тип не использутся для передачи указателя в параметре и твоя функция заведомо не является частью OpenGL API

slackwarrior ★★★★★ ()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от Gremlin_

Connection

Судя по сокетам, OpenSSL, буферам и X509 «можно и догадаться». Но... Но. Но! Можно и обозвать сорцы класса Connection. Слава богу в 2019-м уже давно как не нужно экономить на именах файлов и названиях классов.

slackwarrior ★★★★★ ()
Ответ на: комментарий от Gremlin_

А я не вижу смысла в коде в котором я вижу сокеты, в которых ты не видишь смысла :) Или например... Какое отношение клавиатура имеет к классу Math? Это сокращение от Mathematics? Обозвал бы его Engine или если уж математика — не делал в ней лишнего, кроме подсчетов. И что тогда делает класс Logic? Т.е. после раскопок понятно что там в Math «барабаны крутятся, удача мутится». Но можно как-то это писать так, чтоб не приходилось догадываться. И отделять мух от котлет, а то у тебя в Game.cpp получается интересное явления с рогами, заставляющее задуматься об общих архитектурных особенностях проЭкта:


Math_->keyboard_->keyboard__->Show(); //Но кааак, кэп?

slackwarrior ★★★★★ ()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от slackwarrior

можно было бы и разузнать зачем в openGL GLvoid

Кстати, зачем? Я несколько раз гуглил, но в найденных обсуждениях начинали рассуждать о том, что раньше int был 16-битным, а сейчас 32-битный, и что нужно точно знать число бит, поэтому введён GLint. Но вот про GLvoid никто ничего сказать не может. Приводят ссылки на спеки, где GLvoid просто без объяснений появляется.

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

«перенасимасць» — обычно ультимативный ответ в недрах кэша гугла, ведущего на какие-то протухише холивары на сайте кроноса «на заре времен». Но ок, это можно «стилистикой» API объяснить, чтоб GLvoid* означал то что должен, если тьфу-тьфу на какой-то платформе будет что-то такое с указателем. Но GLvoid sumFunc() уже насрал в достаточно мозгов чтоб они этот каргокультизм переносили и на свой код :)

slackwarrior ★★★★★ ()