Notus

Too fast scroll!? I didn't imagine that kind of situation. Okay, can apply a standard technique to limit speed on games using a timer. But please wait until tomorrow. It's almost Saturday morning in Tokyo.

Bug fix was released. Build0035 beta release 2: Fixed [0002], [0003] Tnanks, kendl The bug you reported was fixed. Please check new release.

kendl, KernelKnowledge12 I compared the 3D Editor with the original Editor on the effect of 'start with surface terrain' button on "New Scenario". As kendl said, town floor setting is different on the data 3D Editor made. As I didn't change this behavior intentionally, it should be a bug. I'll look into it on this weekend.

Scrolling over outdoors, search a secret path on towns... It's also a good beta testing. If you find any odd behavior, please let us know on this board or Project: BoA Editor Remake on SourceForge.net

Only to appreciate maps, it's worth to download. Enjoy!!

Beta call for 3D BoA Editor for Windows Finally, Beta test starts What is the 3D BoA Editor? The "3D BoA Editor" is originally coded for Mac by Isaac, and ported to Windows by Notus and KernelKnowledge12. This application is based on the original "BoA Editor"; all functions of the original editor is preserved (with bug fix). PLUS 3D edit capability. Please see next picture. You can confirm your elaborate drawing simply by touching TAB key without loading the data to the BoA application. Many other features are added by Isaac to this 3D Editor. Please refer "Win3D ReadMe.pdf" in the downloaded file. System This application was tested on next Windows systems. - Windows XP (SP2) - Windows 2000 - Windows 98SE ( Applied latest "Windows Update" on all systems ) Download The files are uploaded to Project: BoA Editor Remake on SourceForge.net Current Version Build0039 (Feb 12, 2005) Update History Feb 12, Build0039 beta release 3: Fixed [0004], [0005], [0006], [0007] Feb 11, Build0035 beta release 2: Fixed [0002], [0003] Feb 10, Build0033 Initial upload for beta test Known Bugs 0001 - Title: Display failure: scroll buttons on the edit screen (Win98) - System: Windows 98SE - Description: Scroll buttons on the four corners of the edit screen are not displayed correctly on Windows 98SE. 0002 - Fixed - Title: New scenario: 'start with surface terrain' setting - System: all - Description: On "New Scenario" menu, floor of the generated town is set to cave floor regardless of 'start with surface terrain' setting - Fixed on: Build0035 0003 - Fixed - Title: Control-TAB: Realistic mode toggle - System: all - Description: Realistic mode display doesn't swap on Control-TAB key input. - Fixed on: Build0035 0004 - Fixed - Title: Realistic mode: Too fast!? scroll speed - System: all? - Description: In some high speed machine, scroll speed is too fast on the realistic mode - Fixed on: Build0039 0005 - Fixed - Title: Key scroll: floor/terrain selection reset - System: all - Description: Current floor/terrain selection on floor/terrain palette is reset to the default when the edit screen is scrolled by number keypad. - Fixed on: Build0039 0006 - Fixed - Title: Disabling 'Change Outdoor Size' Menu - System: all - Description: 'Scenario' menu > 'Change Outdoor Size' isn't disabled when no data. - Fixed on: Build0039 0007 - Fixed - Title: Dialog box: Radio button click sound - System: all - Description: Radio button makes click sound twice - Fixed on: Build0039

All known bug has gone. Now start tests on Windows2000 and 98 to select dll and change system call to manage without extra dll. Goal is near [Edit] Preview version was deleted because Beta test was started

Umm.. The CVS server replied "successfully" when I posted the last update. The scroll (redraw) speed seems to be limited by line drawing. Realistic mode (it works now!!) is much faster than the ordinary 3D mode. As Windows doesn't have screen buffer for redraw, we need make it by ourselves programatically. [EDIT] The reason should be "Clip region". In Realistic mode, only terrain near center is drawn. This feature works as some kind of "Clip region. The all QD routines on Mac is controled by clip region, but on Windows, the custom DIB engine is not involved in clip region schema. My previous guess, buffering using off-screen bitmap, is useful for preventing flicker, but it will reduce redraw speed.

It's because the application is still on PREVIEW state. When beta testing starts, it'll be posted to SourceForge. Currently only source code is posted on SourceForge. You can download PREVIEW version from the link on my previous post, four columns upper. Please read the warning before using it. Replaced the preview version. Major bug was fixed. [EDIT] It takes almost one day that the CVS link appears on the list.

Sorry for double post, Sent the source code to CVS on SourceForge. Win3DBoAEditor/source Next zip file is PREVIEW of the current status of the application. -- Deleted because of Beta test was started WARNING: This application is provided only for PREVIEW of Win 3D editor. This version has so many bug including file write - Fixed on build0028 Don't use it to the actual work. And BACKUP YOUR DATA before loading it to this application. This preview version will work on Windows XP, but not on other System. Actual release will work also on other System. 2D/3D swap - Tab key Scroll on 3D mode will speed up on the release version. Again, This is NOT beta testing, only PREVIEW Have a fun !! [EDIT] Replaced the preview application to new one. Build0032 - Back to Jeff's inheritanceless classes - Replaced file I/O routines to Jeff's original (slightly modified) - Fixed flicker on moving over outdoor section - Fixed blank terrain palette - Fixed start marker on every outdoor section - Fixed Sticky click after change outdoor dialog - Fixed Realistic mode crash - Improved scroll speed

Quote: I'd be in favor of putting it on SourceForge so anyone can look at it. I'll send it to the CVS on SourceForge. Currently I use WinCVS on my local disk for development of this code. I tried to connect WinCVS to SourceForge once, but my effort for a several hours was in vain. I'll setup Tortoise and try again. Quote: Also, the code will compile using GCC (Dev-C++), right? Umm.. Surely it is better to use GCC on our new version, according to the character of SourceForge, though currently I'm not using GCC on Windows. But in this program (the Windows port of Isaac's 3D editor), it takes more time to migrate to GCC now. I want to finish it ASAP, and start new version. Quote: "a) Essential bug was found on the file I/O system." I missed the change I made on the main part of the file I/O affects entire file I/O system. I should rewrite all file I/O routine. Or go back to the Jeff's original on this part. It may be better to go back on this version, and use the new one to the new editor. Jeff's code is far from standard C++, better C at most. I'm going to rewrite it to standard C++ manner, but it was inconsistent to the other part. Thus, rewrite it totally or accept Jeff's manner. I feel frustration to rewrite it totally always, so I want to finish it ASAP. Quote: Notus, check your PMs. Sent reply via Email

Sorry everyone, I should postpone the start of beta testing until next weekend. Many other bug was found. Fixed on build0028 a) Essential bug was found on the file I/O system. Fixed On realistic mode, still crash occurs. Fixed on build0028 c) To improve the scrolling speed, it is needed to rewrite the graphic system in many part, especially on accessing method to scenario data. It takes fair amount of work. KernelKnowledge12, Thank you for answering aliklik If you want the current source code, I'll send it to you. It is developed on MS VC++ .NET 2003. Discussing on the problem of the current code will be useful to consider our new version. Or it's better to mount it on the CVS of SourceForge?

Thank you!! This program is the Windows port of "Isaac's 3D BoA Editor for MacOSX". List up bugs currently known. When all bugs on the next list are fixed, I'll start beta. Bug Fix count down - 0 left Testing further. On another System - Win 2000 - Win 98 Fixed 1) Town mode crash Crash on Item display Research on DIB revealed that Bitmap of DIB does not have sequential address. Thus sequential access to the bitmap caused address violation. Improved 2) 3D mode scroll performance scroll (redraw) is much slower than Mac --> Scroll speed on 1.3GHz Mobile Pentium is comparable (slightly slower) to 933MHz QuickSilver Mac. Fixed 3) Tool palette icon replacement for realistic mode Fixed 4) Tab key - 2D/3D mode swap Fixed 5) "Option-Click" replacement -> "Right-Click" Fixed 6) Dialog Button Behavior A mouse click to dialog buttons responds on the mouse down, not the mouse up. Fixed 7) Town: Corner Wall display in realistic mode failure L-shape walls, NW, SW and NE (terrain number, 6, 7, 9, 42, 43, 45), weren't drawn correctly in the realistic mode. Fixed 8) Import Town Bug Sometimes the imported town has different size from the original, map data (terrain, floor, height and light) are messed up. Fixed 9) "Outdoor: drawing mode failure after moving section" bug. Finished 10) Implementation of "BoA DATA folder preference" Extra: Fixed E-1) Cause flicker when moving over outdoor section Fixed E-2) Small markers moving about in town as if ghost. Fixed E-3) Special encounter is drawn as a white block Fixed E-4) Start on not outdoor but town mode, even if default is outdoor. Fixed E-5) Blank terrain menu is displayed black square. Fixed E-6) Start marker on every outdoor section Fixed E-7) Sticky click after change outdoor dialog

Finally, outdoor part was finished, but...town mode still has crash Please be patient. [EDIT] Wow, tool palette icon isn't changed!? Umm...another bug

Quote: Just an ADT with virtual functions and no pure virtual functions (I don't like pure virtual functions. They tend to make the code messier.). All classes having to do with the game, such as item_record_type, and boat_record_type would derive from this object. No objects having to do with the GUI, or objects such as standalone functors would derive from it. The for_each function is just an example of a function that would increase how generic the overall code is, and therefore make extraneous algorithms easier for others to write. I just wanted to make sure there were no arguments for the ADT. It sounds like only a problem of taste. If you like it, do it. Iteraters such as for_each function can be realized as a stack object when we need it. But it can be a virtual function. I don't have any taste on this. Either will do. Quote: Its not neccessarily the size I'm worried about. Loading all of the .bas file into the memory limits extensibility. I was thinking we could give the program an Multiple Document Interface. By doing this the way I said, or something of the like, the user can work on more than one project at once. Also saving/loading would be done much faster, as only one chunk of the file needs to be loaded. Hmmm, this sounded better in my head. Perhaps I'm not considering something? I also consider on the muti-document editing, because it's Copy/Paste requirement. We should handle multiple documents at the same time to realize copy/paste between two scenarios. Loading all the data into the memory doesn't limit extensibility, except on the memory size. In most of application framework, document class is used to handle multiple documents. In the BoA Editor, a document class will own all scenario data class derived from one scenario data file (.bas). When we expand the feature, the document class will also own extra script data class. It is common concept. I think splitting data between memory and disk introduces another complexity, though the data should be handled as a whole. As for disk I/O, surely it'll increase the loading time but it was within 1-2 sec for the largest zakhazi.bas. On the Windows version of 3D Editor, I’ve already rewritten to load whole scenario on memory temporarily. And saving time will be faster than the original method. To save town/outdoor, first make a copy of whole scenario replacing the edited town/outdoor. Then delete the original and rename the new data. That is, whole scenario data is scanned on the disk to save a town/outdoor. This is a prfered method for data safety. If the whole scenario is loaded on memory, no need to scan it on the disk.

Quote: 1) Is the idea of separating the project into a GUI and a "kernel" a good one, or will it create problems I'm not thinking of? I agree to divide it to GUI and “others”. To share a project, we must divide it in some way. I think there are two point to consider. a) Actual code structure How we are good at in that area. We can make groups of code such as GUI, File I/O, Data manipulation, Graphics. But objects work interactively in many way. The grouping on the code structure is not so strict. In many cases, it depends on only our decision which object (group) a given member or method should belong to. Hence, we can start on the part we want to write at the beginning. After we make an amount of code, we should reconsider on the interaction of objects we made. There are so many blank we should fill. Quote: 2) Notus, you said something about changing the BoA structures' (such as boat_record_type) data members to ints. Is this correct? The data structure on the original editor is based on how they are recorded on the disk. In the disk I/O method, these structures are written or read as a whole block. Though this method is simple for disk I/O, this method restricts object’s function so much. It cannot be even inherited from super object because inheritance adds an extra invisible pointer to the class structure and increase bytes size of the class structure. Another restriction is the data type of class members. To reduce the data size on the disk, in most case one byte type (unsigned char) is used. But on 32 (or 64) bit CPU, one byte type is not efficient on the processing speed, because it should be expanded to “natural” size to feed to the arithmetic unit in CPU. And also, on memory, CPU cannot access to odd address directly. On 32 bit bus, memory is accessed by 4 bytes unit. Thus, one byte type is inefficient on the 32 or 64 bit CPU. Disk I/O doesn’t occur so much. On the other hand, data manipulation is the main part of the code. Hence, I propose to use “int” type as the member type on the “internal” data structure, and make a converter for disk I/O. It surely increases the memory usage, but it is only a several mega bytes at most. Nowadays, a several mega bytes are small part of the whole memory, a hundredth or so even on the old Win95 machine. Quote: 3) I believe all objects having directly to do with BoA's non-visual data should derive directly from an unnamed class that has virtual functions such as for_each( _FunctorT __f ). Comments? Umm, I cannot understand what you mean. Please elaborate more. Quote: 4) For loading towns/outdoor sects from a .bas file, should we create town/outdoor sect structures that keep track of what file they came from, so they can save/load to/from the file without reallocation? I think that whole data (all towns and all outdoors) from a scenario should be expanded on the memory at the same time. It will release us from allocation problem on disk I/O every time we handle the town/outdoor data. And also the reallocation becomes so easy, only we prepare index array to convert the order on the memory to that on the disk. Next is the data size of .bas data Code: perfect.bas 468Kstealth.bas 752kbabysitting.bas 168kCanopy.bas 684kcaveofnoreturn.bas 284kchapmans.bas 168kdiplomacywiththedead.bas 552kemeraldmountain.bas 142kpartymaker.bas 48kzakhazi.bas 812kvalleydy.bas 776k zakhazi.bas is the largest but only 812k bytes. If it is expanded by using "int" type, by four, only 3 Mbytes as a whole. If someone makes a huge scenario in the future, I cannot imagine it is over ten times larger than zakhazi.bas.

The latest bug fix of 3D Blades of Avernum Editor is available from "Project: BoA Editor Remake" on SourceForge http://sourceforge.net/project/showfiles.php?group_id=129871 ---------------- note --------------- 3D Blades of Avernum Editor for MacOSX v1.0.2b4 For users, a) Fixed "Outdoor: drawing mode failure after moving section" bug. Just after scrolling to another section on outdoor, mouse drawing didn't work correctly. And sometimes it caused the 3D Editor crash. This bug occurred both on 2D and 3D mode. This bug was fixed. You can place the 3D Editor anywhere on the disk. The first time the 3D Editor runs, it asks you where is the "Blades of Avernum Files" folder and memorizes it in its preference. Another tips: If you start the 3D Editor just under the "Blades of Avernum Files" folder, it doesn't ask you the place of the folder, and simply starts. But it surely memorizes the place of the folder. Then you can move the 3D Editor anywhere. c) "3D Editor Graphics" file is included within the application itself. No need to place it on the same folder as a separate file. d) 3D Editor stability was improved. However, don't take it as "bug free". It means bugs are also reproduced stably. This is important for us programmers to fix the bug. For Programmers, a) Fixed "Outdoor: drawing mode failure after moving section" bug. EdFcns.cpp Added: check_scroller(), check_scroller_2D(), check_scroller_3D(), process_scroll_click(), handle_scroll(), handle_tenKey() Modified: clean_up_from_scrolling() global.h: modified clean_up_from_scrolling() parameter Preference for "Blades of Avernum Files" folder was added. It makes debug session more easy, as build and debug connects seamlessly. c) The application was adapted to the File Package structure. All resources are included within the application file package. d) Entire resources are moved to data-fork resource file to fit to the CVS system on SourceForge. e) The source code was cleaned up a little. e-1) All warnings are gone. e-2) Most of unused variables, both local and global, are removed. e-3) Local variables which shadow global variables, are renamed. -------------- end of note ------------ Kernelknowledge, Thank you for organizing our effort on making BoA editors and finding the best place to support our project. Without your proposal and quickness, we might still work inconsistently. It takes a while for me to adapt myself to SourceForge system (Mac client for CVS is worst ). But Mac version has been almost finished, and Windows version will be released soon. Please wait a little more.

Isaac, Can we support your 3D BoA Editor on SourceForge? I'm now coding another bug fix, v1.0.2b4, patch for "Outdoor: drawing mode failure after moving section" bug. May I issue the Windows port of your 3D BoA Editor to SourceForge? It entered to debug phase finally. Though there are still a several bugs I know (and maybe tons of bugs I don't know), I hope I can start beta test on next weekend. PS MacOSX and Xcode are CVS savvy. Setup guidance Version Control with CVS on Mac OS X http://developer.apple.com/internet/opensource/cvsoverview.html Introduction to Xcode Source Control Management http://developer.apple.com/documentation/DeveloperTools/Conceptual/Xcode_SCM/Int roduction.html Client for MacOS MacCVS http://cvsgui.sourceforge.net/download.html MacCVSClient http://www.heilancoo.net/MacCVSClient/

KernelKnowledge12, I sent my real name and contact to you over PM for SourceForge registration. You should open Jeff's reply at least. It'll encourage other people who thinks of similar project.

Quote: If your already know this, then I'm not sure I understand why we should create a stand-alone converter. This would just require windows users to edit their scenario and convert to mac format before submitting. Doesn't make sense to me, then again I could be misinterpreting your idea. Hmm.. You are right. I also examined the original code on both platform, and found the editor makes Mac format .bas file even on Windows as the first blank one. When the "Worrior's grove" is used as a template, It's format is Mac type on both platform. Anyway, thank you for correcting me. I've examined only loader/saver part, but initializer. Well, then the stand-alone converter should convert only the resources (graphic and sound). [EDIT] KernelKnowledge12, I read your PM. I agree to it totally. Why don't you open the proposal on the board? We need more participant.

Quote: If you know any other libraries, please mention them. We may not need them for this project, but I'd still like to know of them. http://home.pacbell.net/atai/guitool/ OpenGL As for the OpenGL, I feel it's overkill. a) 2D graphic is plain. Isaac has already established 3D graphic algorithm. Do we need any other graphic method to display the map data? BoA accepts only BMP on Windows and PICT on Mac. Why the editor alone should accept another graphic data format? c) OpenGL only replaces drawing layer. It corresponds 20-30% of the current graphic code. Most of the code is dedicated to modeling. d) It's too heavy for low-end machine. Some users have complaint it's slow even in current 2D/3D editor. Scripting We cannot expand AvernumScript. It's already fixed except little improvement in future. Script parser is used to make our editor scriptable. Hence we should consider which script language the editor would be adapted to. Data format of Mac and Windows The difference on .bas is only next two point. a) "signature" Mac: 0x61d70721 Win: 0xc73d0235 Endian of the multi-byte data. It's possible to handle it on a stand-alone converter. The point is not how we can use the smart tools, but how we can provide smart tools. First, Consider what kind of functions the editor should equip, the means to realize it is latter. [EDIT] I wrote AvernumScript is fixed. It's true, but we can make "Preprocessor" or even "template" handling on it.

KernelKnowledge12, wxWidget seems well in most function as an application framework. It'll be helpful to make GUI. Unfortunately its graphic function requires considerable effort to fit to the editor code in Mac side. Also a several work around is needed on Windows. a) As wxBitmap and wxDC doesn't support PICT, we need to make another wrapper class over these class. It can't enlarge or reduce bitmaps, this function should be implemented. c) wxRect is defined as {x, y, width, height}. On the other hand, Rect (RECT) is defined as {top, left, bottom, right}. Rewriting Rect (RECT) to wxRect will introduce many bugs. Also wxRect::Inside() returns true when given point is on whole boundary. PtInRect() (in both platform) returns true when given point hits top or left boundary, but it returns false when it hits bottom or right boundary. You'll find Isaac's code is filled with Rect operation. Quote: Not too sure why this would be needed. Please elaborate. Most of published and under-development scenarios use custom graphics for floor, terrain, creatures, items and introduction pictures. These graphics needs conversion to be ported to another platform. This conversion involves data format, file format and file name (resource ID) changes. It can be automated by a custom utility. If this utility also supports endian conversion on data (.bas) file, there is no need to implement the "flip blah" function to the editor. And scenario designers are released from conversion, because users can convert the scenario. Also storage size in archive sites can be reduced to half. Quote: The gui will be mostly cross-platform, but will have to use different graphic loading files due to the different resource files inherent in BoA. Actually making GUI will be easy work with wxWidget. Only Tool/Item Palettes needs a little effort. Oh, I forgot about sound. wxWidget doesn't support 'snd ' resource. The graphic (.bmp or PICT) loader method is included in the bitmap class, as this class possesses all data, target file name (resource ID), decompression and the picture itself. wxImage has wxBMPHandler and wxImage::LoadFile() accepts .bmp on Windows. But it doesn't support PICT on Mac, we need to make up them. Mac support on wxWidget (wxMac) is still behind Win and Linux support, as they said in their Web site. However, wxWidget seems better than other cross-platform frameworks among non-commercials. I think this selection is proper at this moment. Boost.Spirit seems to fit to the editor as a script parser. Anyhow, the script parser part of the current code is well packaged. It is surely better to rewrite it for maintenance, but it's not urgent. Phoenix is certainly some framework, but it isn't application framework. Currently It doesn't have functions to support GUI. Isaac, Don't complain It's because we respect your work. And we cannot update your web site. I agree the mechanism such as SourceForge will save our time and effort. Does SourceForge accept the Editor's license ? Dahak and Kelandon, Thank you for many suggestion. I feel Copy/Paste function is definitely needed, too. And also Undo. Customizable palette is the idea brought to me when I touched this editor first. Independent floor, terrain, monster and item palettes would be neat. To realize these feature, we are collaborating now. But I think I should finish Windows port of Isaac's 3D editor first.

I agree to remake it from scratch and use a cross-platform framework. I don't know so much about cross-platform frameworks, but I suppose it'll provide so-called application framework, like MacApp, PowerPlant and MFC. It'll reduce our labor on the event dispatch, mouse/keyboard handling, menu, dialog and components on the main window such as tool/item palettes. Do you have any recommendation on a cross-platform framework? As for the file I/O, "port", endian conversion on the datafork is incomplete in most case. It doesn't care about resources. A standalone utility for cross-platform data converter is desirable. Resource fork of Mac .cmg file will be temporally converted to .rsrc (Resource Manager-style resources) with StuffIt expander when a .sit file is expanded on Windows. This means we can make a data converter from Mac to Win using .sit file even on Windows. In most of data classes, especially data saved in .bas file (scenario_data_type, outdoor_record_type, town_record_type, big_tr_type, ave_tr_type, tiny_tr_type) unsigned char is used. This reduces performance on the execution speed. Nowadays, PC has plenty of RAM. Saving a several hundred KByte memory is nonsense. These data types should be the natural size (int) for CPU. Even if we changes the data size, we only need dedicated serializing method for file I/O. Then we can freely add members to these classes. For example, adding two member variable, type and size, big_tr_type, ave_tr_type and tiny_tr_type are represented by one class. This will encapslate so many conditional branch on the source code. On graphic routines, the problem is more serious. Even the basic data types are different on PC and Mac. Not only the size of data but the order of members. Code: Windows GDI defined in global.h Mac QuickDraw typedef struct { typedef struct { struct Point { LONG x; char x; short v; LONG y; char y; short h; } POINT, *PPOINT; } location; }; typedef struct _RECT { typedef struct { struct Rect { LONG left; short top; short top; LONG top; short left; short left; LONG right; short bottom; short bottom; LONG bottom; short right; short right; } RECT, *PRECT; } macRECT; }; a) Use only common data types defined explicitly on the source code in most of routine, except a several wrapper routines for porting. Do not use simple utility routines provided by the operating system, such as InflateRect(), PtInRect(). Make a compatible one on the source code.

KernelKnowledge12, There are a several things we can contribute to the community a) Porting Isaac's 3D editor to Windows and OS9 Mac Bug fix on the 3D and original editor c) Reorganize the source code or remake it from scratch d) Add more smart functions to the editor I'm working mainly on and a) now. Windows porting is about 70% complete. Anyhow, I cannot imagine how to cooperate on the current source code. We need more ordered source code to share our project. I remember you tried to remake it. Can you open it, as we discuss how to cooperate on it. Dahak, It was reproduced on my side. "Outdoor: drawing mode failure after moving section" bug. Just after scrolling to another section on outdoor, mouse drawing doesn't work correctly. If there is no change on the previous section, the transition to the another section goes without save dialog. Just after the transition, mouse click to the edit screen results nothing. No drawing occurs. If there is any change on the previous section, a save dialog appears on the transition. Just after the transition, moving mouse on the edit screen causes continuous drawing. This bug occurs both on 2D and 3D mode. I'll look into this bug, but please wait until next weekend. (It's Sunday evening now in Japan)

KernelKnowledge12, I don't think we can get so many participants. It's almost torture to track down the source code, as you know. Dahak, Quote: Nevermind what I said about the corner walls. Finally, it passed your strict test? Congratulation. Quote: However, unless I click again (nothing happens!) the editor assumes I am holding down the mouse. In which mode does it occur? 3D/Realistic or 2D outdoor or town