Таймер для бомбы:D

[Arrioh]

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

void Bomb::timeCounter()
{
	time_t time1 = time(NULL);
	time_t time2 = time(NULL);
	int counter = 1;
	for(;;)
	{
		time_t time2 = time(NULL);
		if (time2 - time1 == counter)
		{
			cout << (this->timer+1) - counter << " ";
			counter++;
			if (counter == (this->timer+1))
				break;
		}

	}
}

Нужно смотреть в сторону многопоточности?
SOS!

[rrrFer]

[удалил сообщение]

Нужно смотреть в сторону многопоточности?

нужно

[GreenWizard]

нужно смотреть в сторону рельс и кувалды..... руки ровнять по образцу уж простите за резкость
если же по делу, то в базовом классе игровых объектов прописываем некий метод OnTick, а в основной программе делаем цикл, который каждые Х мс обзванивает игровые объекты.... просто, гибко и удобно т. к. можно реализовать вплоть до ИИ с перемещением врагов или ещё каких-то динамических фишек
читаем http://www.gamedev.ru/articles/?id=70107 или ищем сами про игровой цикл.... многопоточность тоже нужна, но уже для более продвинутых вещей, да и там просто игровой цикл разбивают на потоки, что, при верной реализации, повышает производительность и упрощает код

[rrrFer]

GreenWizard
так-то с onTick все хорошо получится, но придется привязываться к тикам в каждом объекте, что естественно и удобно если связей не очень много. Но например, если надо привязаться к 1, 3, 4, 10, 16,... тикам - то не очень хороший код получится в этом методе.
лучше в каждом объекте хранить список событий (время и колбэк), в онтик у всех элементов списка отнимать некую дельту(которая в онтик передается и значит время, прошедшее с последнего обновления). Если у элемента списка время стало меньше 0 - выполняем колбэк и удаляем событие из списка - это удобней(чем что? - у Вас так и написано, примерно, но я уточнил xD )
Но еще можно на механизмы типа сигналов и слотов посмотреть...они тоже могут оказаться удобны.

А многопоточность то да, резко снизит читабельность кода и затруднит его поддержку.

[GreenWizard]

эх... спор о красоте яиц, но ладно)

Сообщение от rrrFer

GreenWizard
так-то с onTick все хорошо получится, но придется привязываться к тикам в каждом объекте, что естественно и удобно если связей не очень много. Но например, если надо привязаться к 1, 3, 4, 10, 16,... тикам - то не очень хороший код получится в этом методе.

Детали

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

Опять детали реализовать можно по-разному (да и у каждой реализации свои плюсы), но ТСу просто указал направление и самую наивную реализацию (если делать с размахом, то тут и многопоточной, и хитроумные трюки оптимизации, и казино с девушками)

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

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

А многопоточность то да, резко снизит читабельность кода и затруднит его поддержку.

Опять же, смотря что оценивать и как делать..... если весь код, то да, усложнится, но если поток обработки скрыть, ТО код упроститься до некого _Schedule_.AddTask(After_X_ms, @SomeFunction_Or_Object) и будет глубоко наплевать как работает _Schedule_

Но всё это детали, а ТС пусть сам решает как быть... хочет по потоку на бомбу? - ради бога, но пусть сразу создаёт темы про утечку памяти, трудности синхронизации и почему 65я бомба не работает

[rrrFer]

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

имелись ввиду не сигналы типа сигналов Unix, а базовый механизм сигналов и слотов Qt (или аналогичных) - это очень просто, удобно, стандартно.

угу, мы отклонились от темы )