You are not logged in.
Lost Password?

All Posts (jorgeche)




#1
Re: For my next project...
Posted on: 4/15 2:32
Nintendoid!
Joined 2006/3/15
Ecuador
223 Posts
PVBCC 3rdCoderLong Time User (11 Years)
Quote:

VirtualChris schrieb:
I deleted it using Robocopy. But what's weird is that VDBE worked for a while and then stopped because the name got too long. How did it get too long?


I'm not sure about how VBDE's makefile handles the building of its sample projects, since I only work with the VUEngine, but that makefile is a port of the VUEngine's so the problem may be related to what I previously pointed. For the moment, just delete the release folder each time you compile until KR1553 can chime in.
Edited by jorgeche on 2017/4/15 2:46
Top

Topic | Forum


#2
Re: For my next project...
Posted on: 4/15 1:30
Nintendoid!
Joined 2006/3/15
Ecuador
223 Posts
PVBCC 3rdCoderLong Time User (11 Years)
Quote:

VirtualChris wrote:
I can't delete the release folder. It says it's too long.


https://superuser.com/questions/78434/ ... oo-long-for-normal-delete
Top

Topic | Forum


#3
Re: For my next project...
Posted on: 4/15 1:12
Nintendoid!
Joined 2006/3/15
Ecuador
223 Posts
PVBCC 3rdCoderLong Time User (11 Years)
Quote:

VirtualChris wrote:
I opened the file "release" and it had a file folder called "release" and I opened it and it had a file folder called "release." It goes to infinity apparently. It's a wonder I still have room on my hard drive.


This generally happens when the incorrect bulding type is passed to the makefile. Make sure that you replicated exaclty the folder structure of the VBDE sample projects, delete the release folder, and try to compile from VBDE's Notepad++ again (I guess you're using that).
Top

Topic | Forum


#4
Re: Wario Ware: Virtual Boy
Posted on: 3/31 0:37
Nintendoid!
Joined 2006/3/15
Ecuador
223 Posts
PVBCC 3rdCoderLong Time User (11 Years)
Quote:

Inheritance doesn't automatically make scaleable software, abstraction does. But abstraction is not exclusive to OOP or inheritance. A function is a form of abstraction.


And inheritance is a form of abstraction too. But since abstraction makes scalable software, according to you, then inheritance makes scalable software.

I didn't say that there were no other means of making scalable software, nor did I say that abstraction is exclusive to OOP, don't put words in my mouth.

Quote:

Maybe we just pass it to a function then as a const parameter?

void step( const unsigned time );


I don't see what would be the purpose of adding "const", besides self documentation, to a functions' argument that is not a pointer, since you can copy the variable's value into a non constant variable and modify it. But the point wasn't self documentation.

Quote:

Global state can be a problem, but at the same time, all games need it. It's crazy to work in languages that forbid global state...

If we are trying to reuse memory space for game structs, why not use a union? It's a language feature instead of a macro.


You're using a straw man argument and moving the goalposts. I didn't say that globals are to be forbidden, I just implied that they preferably are to be avoided if possible. And I was only responding to your concern about how classes attributes "indicates multiple time variables", which is false, since it is not necessarily the case.

Quote:

The purpose of inheritance is to reuse DATA...


I don't want to derail the thread, whose initial idea is very good, into a discussion about programming paradigms and concepts. If you think that there is no real advantage in the usage of OOP features or libraries that abstracts part of the problem of providing a single interface to work with multiple game mechanics, you're more than welcome to pursue your project as you see fit.

I'm out.
Top

Topic | Forum


#5
Re: Wario Ware: Virtual Boy
Posted on: 3/30 23:14
Nintendoid!
Joined 2006/3/15
Ecuador
223 Posts
PVBCC 3rdCoderLong Time User (11 Years)
Quote:

The game won't be running all 50 at a time, it just runs 1 at a time. You could have as many minigames as the memory allows, and performance will only matter at the level of the individual minigame code itself.


Well performance does indeed matter only at the level of the individual minigame's code itself, but if you don't provide a variable delta time at the level of your "primary game" then you're defeating yourself in your goal of avoiding to reimplement the same solution to the same problem in each miningame, since variable time delta won't affect the minigames that are light enough to run at a locked frame rate, but will allow for those which aren't to adapt their simulations based on the CPU's load. While if you fix the time delta, the heavy minigames, if there are any, will be penalized unnecessarily, forcing the programmer to have to deal with timer interrupts himself if he wants a stable simulation.
Top

Topic | Forum


#6
Re: Wario Ware: Virtual Boy
Posted on: 3/30 22:56
Nintendoid!
Joined 2006/3/15
Ecuador
223 Posts
PVBCC 3rdCoderLong Time User (11 Years)
Quote:

I agree, delta time sounds like it would allow for a much more gradual speedup. Should we use fixed-point as the delta? I would imagine floats would be too slow.


Yeah, fixed math should be preferable since floats are very slow on the VB. In any case, they come with caveats in the way of precision, and their resolution (the number of bits destined to hold the decimal part of the number) needs to be carefully planned.

We use 19 bits for the integer part and 13 bits for the decimal part in our engine for spatial and time calculations, with good enough results, but different games could need different values. In any case, other bit distributions are not difficult to implement.
Top

Topic | Forum


#7
Re: Wario Ware: Virtual Boy
Posted on: 3/30 22:50
Nintendoid!
Joined 2006/3/15
Ecuador
223 Posts
PVBCC 3rdCoderLong Time User (11 Years)
Quote:

If we were to use inheritance from the base game, each minigame would get unnecessary copies of the main game state. Only one minigame will ever run at a time, so the copies of main game state don't need to be a part of the minigame at all. They can exist in one place independent of the minigames that don't need to access it.


Let me explain. The VUEngine has one singleton class called Game that coordinates all the VB's resources, it is the "Operative System". It has a StateMachine that holds a stack of states. In our games, each game screen is a GameState that is pushed into that stack, each with their own stage of game entities, and the Game only updates its current or top most state. Our suggestion is to use GameStates because the state machine pattern is a nice way to swap functionality by using a common interface, and because states generalize common phases liking initialization, execution and exiting. We didn't suggest to inherit from Game (it is not possible in the VUEngine), but from GameState, and we didn't suggest to add the stats to the class that inherits from GameState, but to use a manager, that is a singleton class that holds such values. So no, even in the impossible case of inheriting from the Game class, inheritance doesn't imply that there will be redundant copies of any data.

Quote:

The purpose of a classes and inheritance is to create a template that you can create instances of. However, only one instance of a game will ever exist, so why make it a class?
If we are trying to encapsulate, we can encapsulate at the file level. If you make a variable STATIC inside a .c file, its the same as making a variable PRIVATE inside of a class: it can't be accessed, not even with EXTERN.


No, the purpose of classes is to model software in the same way that we conceive our phenomenical experience which consists of objects that have properties that determine their behavior, and by doing that, problems that are complex to solve using structural programming become easier under the object oriented programming paradigm. The purpose of inheritance is to reuse code and, by polymorphism, to allow for scalability by means of generic programming (among many other things). The fact that there only needs to be one instance of a single class doesn't nullify those advantages.

Yeah, you can achieve something analogous to encapsulation by the use of "static" in C, but you still cannot achieve polymorphism. Still, what this has to do with the suggestion to avoid global variables for the game's stats?

Quote:

There isn't really a difference between:
globals.time
vs self.time?


The difference is in the semantics of the program. Globals allow unrestricted modification of the program's state, while classes' attributes restricts those modifications to parts of the program. This is important because the comprehension of the meaning of a class attribute restricts itself to the class' definition, while the meaning of a global variable requires a comprehension of the program as a whole, a much harder task.

Quote:

Plus, self.time indicates multiple time variables (one per minigame), when in reality we only need one time variable that is applied to all minigames. A global variable makes more sense here because the one parameter would affect everything.


You're confusing classes instances with classes attributes. Inheritance, classes, or OOP in general for that matter, do not imply that all the minigames need to be loaded at the same time in work RAM. Since there is only one minigame active at any time, there needs to exists only the singleton instance of that minigame class in work RAM, therefore only one time variable. When it ends, the instance is deleted and the instance of the new minigame class is created..
Top

Topic | Forum


#8
Re: Wario Ware: Virtual Boy
Posted on: 3/30 21:22
Nintendoid!
Joined 2006/3/15
Ecuador
223 Posts
PVBCC 3rdCoderLong Time User (11 Years)
@syncophono

Allow me to address your points:

Quote:

I think there is value in having a primary game running in a main loop. The primary game keeps track of your score, lives, and the game speed.


All those stats don't need a primary game running, but just a manager that holds their values, potentially saves them to SRAM, and which each GameState (minigames' base class) access to modify their own behavior or to update those stats.

Quote:

Game speed is especially a reason there should be something calling a step function for each game. Because if we want to run at double-time, the main game can call the update function twice.

If each microgame had its own main loop and was running independently, every game would need to individually implement speed-up behavior on its own.


Calling twice or more an update method during a game frame would not be a very good way to affect the simulation's speed. First, because you loose the ability to scale the game's speed using lower than 1 steps (like to increase the game's speed from 1 to 1.5); if the game consists of say 50 minigames, increasing the speed in the way you suggest will be a nightmare to balance since the speed progressing from the first to the last will be too big. Second, the minigames' simulation will depend on their performance, and unless you have absolute control of it, you will end up with objects slowing down and speeding up not intentionally. Third, it could break other processes that may run asynchronously to the minigame's logic (like VIP's o Timer's interrupts, for example).

To avoid those problems, and maybe others, but at the same time to achieve the desired effect, modern game engines pass to the update methods a deltaTime argument that can be scaled by the programmer. That way the simulation is not dependent on the game's performance, the scaling can be non linear and async processes are not affected. The VUEngine's GameState's execute method passes such a value to the game objects, but it is only used to affect animations (that is, the engine's classes only use the time delta to affect the animations' speed, but derived classes specific to each minigame could use the time delta for other purposes), while things like physics simulations are updated by another facility.

Speed scaling can be implemented in a GameNameGameState class from which all minigames inherit. In this way, the "primary game" doesn't need to exist, since it would just be logic shared by all minigames, achieving your goal of avoiding the need to reimplement on each one the same functionality.

Quote:

On game speed, what do you think about implementing speeding up? Is calling the update function multiple times adequate, or maybe some VUEengine parameters can be tweaked?


As I said before, calling multiple times an update method during the same game frame wouldn't be a good idea in general, no only in the context of the VUEngine. On the other hand, adding support for time delta scaling to the engine would be easily done.

Quote:

If the programmer needs access to the time remaining, we can expose it in "common.h".


By using inheritance, there is no need to use global variables. The time remaining would be a protected attribute of the GameNameGameState class accessible to all the minigames.

jorgeche
Top

Topic | Forum


#9
Re: Insect Combat
Posted on: 3/28 22:07
Nintendoid!
Joined 2006/3/15
Ecuador
223 Posts
PVBCC 3rdCoderLong Time User (11 Years)
Quote:

VirtualChris schrieb:
You can download the latest ROM here:
www.atari2600land.com/insecticide/ic20170324.vb


Hey, I was finally able to test your game on the VB to try to reproduce the problem that you're experiencing. I was able to see it only by quickly turning on and off the VB while on the character selection screen, and I only noticed different behavior in the third screen.

Here are a couple of things that you may want to check:

1) Make sure that all variables in the problematic screen (where the ant passes by) are properly initialized.
2) Make sure that you are erasing all BGMAP and CHAR memory when entering that screen and before drawing anything to it.
3) Make sure that you are controlling properly the WORLD layers that each image is assigned. It is possible that the ant and the label are being rendered behind the background.
Top

Topic | Forum


#10
Re: Insect Combat
Posted on: 3/25 13:53
Nintendoid!
Joined 2006/3/15
Ecuador
223 Posts
PVBCC 3rdCoderLong Time User (11 Years)
Quote:

VirtualChris schrieb:
I'm just going to give up on the whole thing. I can't fix it so the game displays the logo and ant on the intro screen. Here's what I've been doing:
>Starting the game. Everything goes as normal.
>Turn it off at the fighter select screen.
>Wait one second.
>Turn it back on.
>The ant does not display where it is supposed to be.
WHY?!


Could you send me a ROM? Maybe I'm not fully understanding the problem and seeing what is happening could help.
Top

Topic | Forum