[11:16] ok then i have the kanban open [11:17] sry, brb in 1' [11:17] ok [11:18] back [11:18] ok [11:18] so thomasz can you summarize what is the aim of the task and what you achieved right now? [11:18] ops [11:18] theodor [11:19] ok [11:19] so the basic idea is the following: [11:19] we need a framework that receives a map and draws it [11:19] more specifically [11:20] we need one framework that given a map object it loads the appropriate image [11:20] that's 1. and 2. of 133 [11:20] ok did you already modified the xml for the map and map metadata? [11:20] and this has been coded [11:21] no [11:21] we need not do such a thing [11:21] I mean given that a tile is GRASS where do you get the data? [11:21] From the tile type name [11:21] ok then you ask the repository to handle you the right image right? [11:21] yes [11:21] ok [11:22] Tomasz any question right now? [11:22] no [11:22] ok [11:22] ok [11:22] for .3 of 133 [11:22] There are two things here [11:22] yes [11:23] just tell us (the point here is not so trivial since we are in isometric) [11:23] Firstly, when we draw a map, we don't want to draw the whole of it, rather just a part of it [11:23] sure we have a view [11:23] a partial view [11:23] and secondly, what you said, everything must be drawn in an isometric way [11:23] yes [11:24] this task has to figure out these conversions: from full to partial to isometric [11:24] ok what I would do here is this thing [11:24] and in the opposite direction [11:24] since we use TDD and we can integrate things later, [11:24] when you say partial view you mean screen view or explored view [11:24] screen view [11:24] ok [11:25] fog of war is another point [11:25] and it will come later (much later i believe) [11:25] what i would like to have here just to achieve the project [11:25] is to have a separated framework that takes data in input and visualize the map [11:26] so this is subtask 178, Manish wanted to do it, but in the end he didn't [11:27] yes i see [11:27] however task 178 is not well defined [11:27] i would say [11:27] was is discussed? [11:27] yes [11:27] yes but is very general [11:28] ok, should we refine it now? [11:28] well [11:28] first of all how would you call this object? [11:28] MapRaster? [11:29] hmm, MapRaster would imply more functionality, this object only does coordinate conversions [11:30] ah ok [11:30] CoordinatesConverter [11:30] should be ok [11:30] but about the visible part of the map that is a sort of raster [11:30] I mean it cut all the things you cannot see in the screen [11:31] yes it is [11:32] but does it matter? [11:32] So in the TDD way [11:32] we will make 2 objects [11:32] the first one calculates all visibile parts [11:32] the second one calculate the isometric view starting from the visible parts [11:33] we follow the single responsibility rule [11:33] ok [11:33] any questions tomasz [11:33] ? [11:34] yeah [11:34] then fire out :) [11:34] class is receiving coords about screen and calculates it [11:35] as far as i understand you visible parts are inside screen [11:35] oh, actually in the description there's a mistake, we need the dimensions (pixels) of the canvas we draw on, not the whole screen [11:35] yes [11:36] something like 800x600 [11:36] instead of the whole screen [11:36] that can be at least 1024x768 [11:36] ok so we receive resolution and starting point of the screen? [11:36] starting point of the view [11:37] which is coord from whole map right? [11:37] well it should be the 0 point of the map [11:37] 0,0 [11:37] ops sorry [11:38] 0,0 point of the map view [11:39] ok [11:39] hmm [11:39] I kinda lost you there [11:39] obviously recalculated in pc screen coordinates [11:40] yes? [11:40] but we don't need the screen resolution and the canvas's low-left corner if you meant that [11:40] the canvas has its own coordinate system [11:40] if I'm not mistaken [11:40] what i wanted to know is [11:41] the input is coord of the whole map + size of the screen? [11:42] yes, something like 60,60 and 800,600 [11:42] for example we got map 100x100, and we receive (30,40) point from whole map [11:42] we must keep in mind that a tile will have a size in px too [11:43] so the output is in tiles or pixels [11:44] i would say in pixels [11:44] or it depends in how many calculation you want to do [11:44] yes, and actually need the center pixel, of where we are going to draw [11:44] we need* [11:45] so input is center point not a corner [11:45] no the input might be the corner [11:45] say we want to draw whats on tile 0.0 [11:45] yes [11:46] because map coordinates are 0,0 0,1 etc [11:46] sure [11:46] but when we want to draw 0,0 on the screen we will draw it on many pixels [11:46] right [11:46] so question is: do we have const number of pixels per tile? [11:47] depends, do we want to zoom? [11:47] we could have it later [11:48] so to start we can have a fixed size [11:48] NxM [11:48] just to handle the isometric [11:48] the thing is [11:49] if we receive corner tile, it won't be drawn [11:49] as a full tile [11:49] in isometric [11:49] well, it depends on how we'll define the coordinate system (zig-zag etc) [11:50] but I think that we can go back to it later when we have a working prototype [11:50] since solving it is easy, we just draw one more line [11:50] and clip it [11:51] ok lets' start from a really basic thing [11:51] after that we just need to add modifitations [11:51] to complete the view [11:52] as theodor said [11:52] brb just go on with the discussio [11:53] also, I think this problem will be dealt with in the framework that will use this coordinate converter [11:54] ok [11:55] so what will be our output in basic form [11:55] we give a map coordinate say 5,6 [11:56] and receive a pixel coordinate say 502, 402 [11:56] which means that whatever is on 5,6 [11:56] should be drawn with its center on 502,402 [11:58] i get it [11:58] ok [11:59] how to do the clipping on the screen view befor that? [11:59] the basic idea is this: [11:59] so we avoid to calculate all choords? [11:59] oh you mean for the visible map? [12:01] yes [12:01] simple: [12:01] this is a step we must do before [12:01] say that the whole map is NxM [12:01] and the visible portion is nxm [12:02] when we convert to the screen coords [12:02] we do it from the nxm [12:02] ok [12:02] right [12:02] and map to it the NxM portion [12:02] sure the coordconverter is not aware (and it must not be) of wich tile you pass and if the tile is visible [12:03] it just converts [12:03] this is good [12:03] my initial idea was this: [12:03] the converter can be set to which portion is visible [12:04] ie we setVisible(X) [12:04] and it does convertions to and from X [12:04] then we setVisible(Y) and so on [12:04] mmm [12:04] i do not like it [12:05] since an object must do only a thing [12:05] lets' say that the converter converts [12:05] we will implement some other object that clips away [12:05] starting from the gamw pam view [12:05] game map [12:05] is cleaner [12:05] and is testable [12:06] well, if we do that we need to provide the clipped map size to the converter on each convertion [12:06] well not the size [12:06] its "position" to the map [12:06] eac time you move the map you must do it [12:06] ok [12:07] just think when you will move a unit [12:07] moving the map will be tile by tile [12:07] you will recalculate all visible tiles in the map [12:07] or it will be more direct? [12:07] yes but you need to calculate which tiles "are now visible" [12:08] damn isometric, i had optimalisation idea xd [12:08] so pheraps the more optimized way to do this is : [12:08] 1) calculate visible tiles [12:08] 2) calculate corrdinates to screen [12:09] each time you move the view of the game [12:09] but aint i right [12:10] yes? [12:10] hmmm [12:10] i like it [12:10] that there will be const pixel point for each tile in whole map size? [12:10] if the move will be tile by tile [12:11] the move will be X x 2X pixels [12:11] exactly one tile in isometric [12:11] or 2X x X [12:12] so mapping it first, and then catching wouldnt be faster? [12:12] instead of recalculating after each moving of the map [12:12] you mean mapping the whole map in memory? [12:12] as a sort of cache? [12:12] yes [12:13] sure it is [12:13] very slow at the beginning i believe [12:13] but the game will be in startup phase [12:13] we can handle it [12:14] anyway [12:14] right now we need to create a coordinate conveter [12:14] that does not care where the data come from [12:14] it just coverts [12:14] and it is want we want to have as little brick :) [12:14] i have a question about method 3 [12:14] which is calculating from pixel to tile [12:15] we want to be able to do this conversion in the opposite direction [12:15] input of this method will be center pixel or any pixel from tile area [12:15] ie when something is clicked on the map [12:15] anything [12:16] well, we could also like this method for later, since now it is of no use to us [12:16] brb in 1' [12:16] I believe it will be the center pixel of the object [12:17] something will have to figure out which is the center pixel [12:18] either the converter or something that calls its method [12:18] well these will be constants of the GUI [12:19] lenght, height and number of pixels for a basic tile [12:19] i would not take care of those values right now [12:19] so first of all we need to know which tile will be input for the class [12:19] we just say they are constant [12:20] we just pass the map coords [12:20] ex : 0,0 [12:21] inside we will have the constants to calculate the roght pixel of the screen [12:21] so to summarize [12:22] and modify the task [12:22] task 178 i mean [12:22] as far as i understood, the method will calculate single pixel with single tile input, but based on class constructor tile [12:22] which will define entrance point for the screen [12:25] theodor? [12:25] here [12:25] well what i do not understand here is: [12:25] how to calculate all points of the tile? [12:26] we don't have to [12:26] we do not [12:26] right now we can calculate only the center poit [12:26] point [12:26] do we need another point? [12:26] we only need that [12:26] if we now the center [12:26] just asking who then draws all the tile starting from that point over the canvas [12:26] we rotate and scale the image and draw it aligned on that center [12:27] yeah i wanted to ask question about [12:27] tiles, which got center outside screen [12:27] we can do that because we know the center pixel and the dimension of the tiles on screen [12:28] we wont draw them [12:29] well actually we'll draw them and clip the extra [12:29] but as I said earlier we can deal with this after we have a working prototype, so that we aren't blind working [12:30] ok, so we care right now only about tiles with center pixel inside the screen [12:30] yes [12:31] ok can you modify the task so that it talks about only the coordsConverter? [12:31] delete the "visible" part? [12:33] point 1 and 3 are not related to choord converter [12:33] ok [12:34] actually 3 is related, it's the opposite convertion [12:34] yes so we discuss also about that? [12:34] so that the converter can do both sides? [12:34] but like I said it will become useful later, when there will be mouse interaction [12:35] well, if we have the equation for 2 [12:35] yes but task 178 is related to choordconverter [12:35] so we define the converter [12:35] ok? [12:35] we just need its inverse for 3 [12:35] yes [12:35] so, at this stage we only do 2 ? [12:36] and if you want 3 [12:37] dunno, its useless now [12:37] tbh, point 3 is easy to implement after we got point 2 [12:37] y [12:37] ok cut out all not needed features then [12:37] ok lets' impelemnt also point 3 then [12:38] so we have double way conversion [12:38] and that's it [12:38] ok, but there's only one more thing we have to do for 3 [12:38] that is? [12:39] because its not guaranteed that the centers are clicked [12:39] so for every click we'll have to figure out which is the center of that tile [12:39] still we need to have knowledge about size of tile (even fixed) [12:40] the question is, will the converter do it? [12:40] or the caller? [12:40] of the converter [12:40] using first method 3 and afterwards 2 will give u center, so mby caller [12:40] lets' assume that the center pixel is passed [12:40] ok [12:41] this is not a problem of the converter [12:41] but we need to define which tile is passed as constructor of this class [12:42] no, the tile is an argument for the converter's method [12:42] yes [12:43] so, shall I put it on the board, or will someone else do it? [12:43] and it is just the cohhordinates [12:43] just modify the task [12:43] ok [12:48] is it ok now? [12:48] let me see [12:49] we can assume that we have a fixed size tile right? [12:49] we just take the old tileset of the old version [12:49] even if we don't [12:50] we can figure it out if we have the dimensions of the whole and the visible map [12:51] well 800x600 is the minimum i believe for the map view [12:52] at any point we can read the dimensions, so it is not a problem [12:52] sure [12:53] but we just need to pass parameters if needed by the converter [12:55] if zoom is not allowed [12:55] then the sizes are fixed [12:55] so it is not a problem [12:56] zoom will be a feature [12:56] so we just need to pass neede parameters even if we do not use them now [12:56] or at least later we refactor the code [12:57] I say, we refactor the code when the time comes [12:58] ok [13:02] so [13:03] sry, but I'll have to log out in a while [13:04] ok [13:04] so next chat when? [13:04] everyday after arround 18pm i can join any chat [13:04] 6 pm [13:05] I'll be available from Thursday [13:05] I'm sitting two exams, one tomorrow and one on Wednesday evening [13:05] so I'm kinda full for these days [13:05] ok [13:06] so are you ok if we assign this task to Tomasz? [13:06] y [13:06] and we chat againg next sunday? [13:06] we will see the time later? [13:06] but I would say at 10.00 (11.00) for theodor [13:07] okay [13:07] as long as it isn't something like 08:00 I'm okay [13:07] so ok task 178 is assigned to Tomasz [13:07] but i dont know some thing about constructor of this class [13:07] i will send this chat log [13:07] and we chat again next sunday [13:07] ok [13:07] will mail for reminder [13:07] ok then see you later