Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Milhouse

#1
Quote from: Crimson Wizard on Mon 31/12/2012 14:04:34
I may remove that reference (you may do that for your local copy meanwhile).
I tried that but there's code used in that project that depends on that reference!
Quote from: Crimson Wizard on Mon 31/12/2012 14:04:34
Second thing is that the Native project, as well as Engine, is not compatible as-is with MSVS 2010. I think certain fix could be made: open Project properties, "General" -> "Platform Toolset" -> should be set to v90. But you have to have at least 2008 Express installed. IIRC that worked for me.
That'll take a while getting it running. At the moment I'm short on time.
#2
Quote from: Crimson Wizard on Mon 31/12/2012 07:52:24
I feel like this is going more offtopic
This might be off topic again...
I'm not able to compile the github version. For AGS.native the linker isn't able to resolve some external references (e.g. symbol __rgb_a_shift_32). As the editor depends on that assembly at compile time I get an error message (could not load referenced assembly). Might someone check the AGS.editor.full solution or provide me with information to solve that problem? Btw the editor of the SVN version I checked out earlier didn't depend on the native assembly. I'm using VS2010 Ultimate on a Win7 64 bit machine. Thanks.
#3
Quote from: Monsieur OUXX on Sun 30/12/2012 15:11:33
But if you ask questions on the forum, as you can see people are glad to help, and overall the result is very good!
I have noticed that and appreciate it very much. I hope you don't mind my jokes :)
#4
I just know SVN well and have always used the folder structure suggested by the SVN makers. That way it's also easier for a new member of the development team to be productive right from the beginning. GIT uses a more modern approach and if I had a new project I would go for it. Also I would stick to the suggested workflow of the git makers. There is an open source git book available at the git web site that also suggests branching work flows. I would be glad if I just had to learn from that source. No adventures ;)

If I had to decide, I would close the SVN repository as it's already hard enough to manage and have the overview of one repository. Just my two cents and own experience.

And I agree with Crimson Wizard that you should know how to organize versions. That's the task of a project manager or project manager team. Who has done that task so far?
#5
For me (new to AGS) it is not clear in what direction AGS is heading to:
- 2D retro (fan) games with easy to use development tools
- "state of the art" adventure games playable on multiple platforms with the option of using 3D characters or even environments (probably steep learning curve)

The first group (artists) probably isn't interested in learning how to handle exceptions and all the stuff a full featured programming language comes with. My guess is they will be fine with the current language. The second group is probably afraid of having to switch to another tool and drop AGS in order to get their (commercial) adventure games running in less time/for less money, etc. Lua also seems to be a kind of standart in game programming. So probably developers having used other tools with Lua support would have an easier start / be easier to find.

So the actual question to be answered is in what direction is AGS supposed to go? 8-)

Marcus
#6
Quote from: BigMc on Sun 30/12/2012 04:04:28
How to submit a patch.
You seem to have many many repositories... And good that I asked because I've used used https://svn.adventuregamestudio.co.uk:7743/svn/ags/trunk/ instead of https://github.com/adventuregamestudio/ags. What's the reason for so many repositories and branches? I haven't found any sticky note explaining that "mess" (sorry for that) for someone new to the topic. Or is this intended to be some kind of adventure everyone has to complete before contributing similar to the forum registration quiz? (laugh) Just wondering ;)
#7
Quote from: tzachs on Sat 29/12/2012 22:24:39
Regarding #2, from looking at your mockup the only issue I see that you are limiting the number of walkable areas to 15, which can pose a problem for ambitious games.. If you come up with a way around that I'm on board
I could imagine to start with e.g. one of the controls at http://www.codeproject.com/Articles/12327/Office-2003-Color-Picker and modify it for walkable areas etc. Suggestions?
#8
Quote from: tzachs on Sat 29/12/2012 22:24:39
and feel free to code it since you've confessed to have experience in dot net ;)
I've already had a look at it ;)

What I found was a nicely designed architecture with quite a learning curve. It would be a lot of effort to change the toolbar so that it could keep other controls than icons. From this point of view the palette control would be in better company close to the other non toolbar icon controls like the zoom and trans sliders. Any suggestions?

Btw. is there somewhere information about how to submit a patch and allowed namespaces? E.g. is it allowed to implement drawing routines for custom controls and mess with windows messages? I'm asking because future compatibility to mono seems to be important (in other threads).
#9
Quote from: Crimson Wizard on Sat 29/12/2012 22:57:49
AGS currently supports only 15 areas per room.
However, AGS supports 50 hotspots. And the implementation of hotspots derives directly from walkable areas. So if you e.g. switch from walkable areas to hotspots the palette control has to deal with that. Of course, in such a case the palette control could be switched to being invisible. But due to the inheritance dependencies I found in the code, I think, the patch would be smaler, if the feature was implemented for hotspots, walkable areas, walk-behinds, and regions.
#10
Regarding suggestion #2 - Here's a mock example of how this could be implemented:

I didn't place the pallet close to the properties area, but instead to the toolbar where you normally expect such a feature. Of course, the current selection and the walkable area selection list had to be synchronized in both ways. And if you moved the "Select area" tool from the left closer to the pallet it would be even better grouped in regards to functionality.
#11
In suggestion #1 I've claimed there is a bug that sets the walkable area ID to 0. This statement is incorrect! :-[ It seems that I've set the walkable area ID to 0 by myself. This has happend because I was "exploring" the walkable area feature by left clicking with my mouse. As the "Select area" tool is the default, the walkable area ID was set to 0 without me (unfamiliar with the feature) recognizing that.

Ok, it seems like it's a feature, but to be honest, I still think it's a usability bug. It could be solved by selecting  a different tool than "Select area" as the default one.
#12
Hello guys,

For the last two days I've been playing with AGS and especially one issue has cost me a lot of time: I wasn't able to draw walkable areas.
Ok, now after hours it's clear to me how to use that feature...

1. My experience
I was told by a tooltip that "You are currently using the eraser. To draw new areas, change the selection in the list above the Properties Pane." Well, in all other tools I know you have to click an eraser icon or select that command from a menu in order to enter such an mode. I hadn't done that. Also I wasn't able to locate the walkable area ID selection list ???. This was probably due to the huge width of that control. I just wasn't able to identify it as a list control. Ok, maybe I'm stupid... :-[ But let me tell you that I've been a software engineer for seven years. And developing .NET user dialogs has been one of my tasks. The help or FAQ don't mention that problem. Finally, I was able to solve that issue by using the search feature of this forum: A post with a screenshot how to change the walkable area ID to something else than 0.

2. Why you have that problem following a tutorial
I was watching the youtube tutorial by densming. So I started a new project with the default game and switched the background. I was notified that the new background had a different size and everything including the walkable areas would be deleted. Ok, the first time I didn't read that message box, but that wasn't the problem. The problem is: After deleting the background image of the only existing room and deleting the walkable areas due to the new background size, the walkable area ID is set to 0 and remains zero unless set to something else manually.

3. Two suggestions to remedy that problem.

  • After assigning a background image with a different size and deleting the walkable areas make sure to set the walkable area ID to non edit mode. Note: That buggy behavior does only appear in case there is only one room! (repoduction is quite easy with a new project and the default game) Also it might be of help for beginners to change the selection text from "walkable area ID 0" to "walkable area ID 0 (eraser mode)"
  • Walkable areas and other regions are not object oriented. Instead, they are internally implemented by using image files and color codes to code the different regions. From that (developer) point of view it makes totally sense to have an eraser mode assigning color code 0 to pixels. However, there are users not familiar with that part of AGS history, instead, they are familiar with object oriented tools. So, they first try to treat walkable areas as objects. The editor supports that thinking as every walkable area has properties assigned to it. So it seems naturally to have walkable areas overlap each other. But that's not possible as each walkable are pixel is only able to keep one color code. Also from an object oriented point of view it doesn't make sense to draw into one walkable area in order to delete other walkable areas. My suggestion is to change the selection list to a color pallet to make it more obvious that it's a actually a drawing tool for a 2D image. The colors could be arranged in two rows each of them keeping 8 colors. This way each color would be big enough to keep the ID of its walkable area as text. Also the Properties Pane could still be used as it would show the properties of the color currently selected.

I'm looking forward to getting feedback for suggestion #2. However, suggestion #1 describes a bugfix and should be implemented ;)

Regards
Marcus
SMF spam blocked by CleanTalk